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(54) Decision support system for the management of an agile supply chain 



(57) A decision si43port system for the management 
of an agile supply chain that provides an architecture 
including a server side and a client side. The server side 
includes a dec^ion support system database that inter- 
laces with model engine that performs analysis of the 
data to support planning decisions. The server side 
includes a server manager that coordinates requests for 
sendee and information. The dient side includes ded- 
ston frames that present the various view points availa- 
ble in the system to the users. A frame manager 
coordinates the requests from decision support frames 
to access the needed data and models. The decision 
support frames provide a view into supply cfiain and 
integrate analytical models responsive to the view point 
of a business process such as demand management 
Tlie frames indude a sipply management frame, a 
demand management frame, a vendor managed 
replenishment frame, a Planning, Sales and Inventory 
planning frame and a distribution network design frame. 
The model engine indudes a component procurement 
policy development module, a finished goods distnlxj- 
tion network design module, an aggregate production 
planning module, a finished goods inventory manage- 
ment module, a sales forecasting and planning module, 
a market data analysis module, a verxfor managed 
replenishment module arxj various utilities such as 



generic linear programming solvers aixJ statistical anal- 
ysis routines. The system also indudes a demand and 
supply recondliation process recondling production, 
sales and inventory and recoTK^iling a top-down forecast 
with a bottonD-up forecast where an expert t>ased model 
is used for the bottom-up forecast A capacity planning 
process determines the feasibility of a capacity plan 
responsive to supply constraints. A vendor managed 
replen^ment process plans inventory replenishment 
analysis and periods responsive to predicted sales and 
supply constraints. A scenario management process 
assodated with all frames enables the user to analyze 
different hypothetical scenarios for comparison of kxjsi- 
ness plans. The frame manager indudes a system inte- 
^ator and a fonctfonal integrator. A database 
management system manages the supply and mainte- 
nance of information needed t>y the modeling proc- 
esses through the frame manager. A domain 
management process limits data availat)le to said 
frames responsive to a user selection. 
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Description 

BACKGROUND OF THE INVENTION 
5 Reld of the Invention 

The present Invention Is directed to a system for supporting managenient decisions associated with manufacturing 
of service supply chains that span from a point of creation to a point of consumption and, more parttcularfy. Is directed 
to a system that allows the various decision makers in the si4)ply chain to view the supply chain from their own perspec- 
10 five, obtain information and evaluate dectsior^ concerning past, current and future performance with respect to a 
diverse set of often conflicting goala 

Description Of The Related Art 

15 Many types of manufacturing database management and inventory control systems exist today. Each of these sys- 
tems views the process from the nanrow viewpoint of the goate of such a system. For example, inventory control proc- 
esses tend to determine when the inventory of an item is projected to be depl^ed and when to order goods to prevent 
such depletion. The inventory control process does not generally take into account the problems associated with avaO- 
atMlrty of materials and machines to satisfy tiie inventory demand. On the other hand the manufacturing corrtrol process 

20 considers the availability problem but does not take into account the effect of a sales promotion that will deplete an 
inventory faster than projected. A marketing department in preparing a sales promotion will often not consider the effect 
that promotion will have on availability, inventory and profit margin but terKls to focus on sales goals. What is needed is 
a system that will si4>port managers with each of tfiese view points in understarxiing the effect of the various decisions 
tfiat can be made on the supply chain as a whole txyth cunrently and into the near futura 

25 

SUMMARY OF THE INVENTION 

It is an object of the present invention to provkie a system tfiat allows a decision maker in a supply chain to view 
the chain from their own perspective and mderstand the effect that their decisior^ will have on the supply chain as a 
30 wfK>le. 

It is another object of the present invention to provide a distrixjted and layered architecture that allows the reuse 
of processing resources and data in making diverse different view point deepens concerning a supply chain. 

It is also an object of the present invention to provide a User Interface tiiat projects a view (a Decisk)n Support 
Frame) into the supply chain that takes into account the view point of the particular user, such as a plant manager or 
35 sales manager. 

It is arx>ther object of the present invention to provide quantitative models and analytical processes to support the 
plans prepared and decisions rnade from the varkxjs supply chain view poinis such that tfiese resources are cost e^ 
tively provided and utilized in across the entire supply chain-wida 

It is also an object of the present invention to provide a scenario management system in whk;h Scenark>s can be 
40 saved, modified and data transferred t>6tween view points or frames. 

Kisafulherobjectof the present invention to allow tfie user to specify a data donmin that lirnits the data used for 
a particular view point. 

It is an adcGtional object of the present invention to provide a system that will reconcile the demand and supply 
aspects of a supply chain. 

45 It is still another object of the present invention to allow the creation of an integrated production, sales and inventory 

(PSO plan and provide a projection concerning what is feasit)le in the production, sales and inventory plan. 

It is an object of tiie present invention to alkw the manufacturer or vendor to plan the supply of goods and services 

for a customer that integrates all information about a product, including current, past and projected future sales and 

inventory, Into a feasible replenishment plan. 
50 It is a further object of the present invention to provide a planning process that recondles top dow^ 

projectiona 

It is an object of the present invention to provide expert based nnodels that alfow forecasts from various view points 
including a bottom up view point 

It fs also an object of the present invention to operate in an interactive and dyriamic decision environment providing 
55 decision support to single or a set of users. 

It is also another object of the present Invention to niaintain overall data consistency and pro^ performarx^efeed- 
t>ack to users reflecting the impact of local" decisions on global supply chain performance. 

The above-identified objects can be attained bf a decision support system for the management of agile supply 
chains that provides an architecture including a server side and a client sida The sender side includes a decision sup- 
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port system datat)ase that interfaces with one or mae model engines that perform analytical processes on the data to 
determine requirements and make projections. The server side includes a serv^ manager that coordinates requests 
for service arxl information. The client side includes Decision Support Frames that present the various view points avaO- 
at)le in the system to the users. A frame manager ttiat coordinates the requests from Decision Support Frame (view 
5 points) is presided tyy the system to access the needed data and rrxxiets. 

These together with other objects and advantages which will be subsequently apparent reside in the details of con- 
struction and operation as more fully hereinafter descrit>ed and claimed, reference being had to the accompanying 
drawings forming a part hereof, wherein like numerals refm* to like parts throughout. 

10 BRIEF DESCRIPTION OF THE DRAWINGS 

Rgure 1 DSS System Architecture in the Context of Manufactuing Supply Chains. 
. Rgure 2 DSS ^stem Architecture in tfie Context of Equ'pment Repair Supply Chains. 

Rgure 3 Decision Support Thread. 
t5 Rgure 4 The Data Spaces in Supply Chain Managemerrt 

Rgure 5 Structural Elements in the DSS Datat>ase for the Manufacturing Supply Chain. 

Rgure 6 Structural Elements in the DSS Datat>ase for the Equipnient Repair Supply Chain. 

Rgure 7 Spedftcation of Decision Support Frama 

Rgure 8 Decision Processes in the Manufacturing Supply Chain. 
2o Rgure 9 High Level Model of an Equ'pment Repair Supply Chain and the Decision Processes. 

Rgure 10 Process and Data Rcw Diagram Legend. 

Rgure 1 1 Data Space Associations of the Demand Management Frame. 

Rgure 12 Process Row of ttie Demand Management Frame 

Rgure 13 Process Row of Order Fulfillment. 
2s Rgure 14 Data Rcw for the Demand Management Frame. 

Rgure 15 Data Space Associations of the Production-Sales-lnventory Planrvng Frame. 

Rgure 16 Process Flow of ttie Production-Sales-Inventory Planning Firame. 

Rgure 17 Data Row for the ProductiorvSales-lnventory Planning France. 

Rgure 18 Data Space Associations of the Supply Management Frame, 
sa Rgure 1 9 Process Row of the Supply Management Frame. 

Rgure 20 Data Row for the Supply Management Frame. 

Rgure 21 Data Row for ttie Supply Management Frame. 

Rgure 22 Data Space Associations of the Vendor Managed Replenishment Frame. 

Rgure 23 Process Row of the Vendor Managed Replenishment Frame. 
35 Rgure 24 Data Row for the Vendor Managed Replenishment Frama 

Rgure 25 Data Space Associations of the Distrbution Network Design Frame. 

Rgure 26 Process Row of ttie Distribution Network Design Frama 

Rgure 27 Data Row for the Distrfoution Network Design Rame. 

Rgure 28 Seven ModiJes and Supply Chain Management 
AO Rgure 29 Pareto Analysts for ABC Classif Nation. 

Rgure 30 Scatter Ptot for Sales-Volatility Classification. 

Rgure 31 Impact of Sales Promotion. 

Rgure 32 Curve Rtting for Promotion Effect Analysis. 

Rgure 33 System Level Servk^es, the Seven Modules and Model Engine Utilities. 
45 Rgure 34 Supply Chain Frame Manager: High Level Architectura 

Rgure 35 High Level Architecture of the System Integrator. 

Rgure 36 High level object representation of the system integrator portion of the frame manager. 

Rgure 37 High Level Architecture of the Functional Integrator. 

Rgure 38 Data Row Dia^am for ttie Sif)ply Chain Network Configurator. 
so Rgure 39 Functionality in the Domain Manager. 

Rgure 40 Hierarchical Structure of a Scenaria 

Rgure 41 Data Row Diagram for the Performance Simulator. 

Rgure 42 User-DSS Interaction Process. 

Rgure 43 Sarrple Saeen from PSI DSS. 
55 Rgure 44 Three-tier Application Development Architecture. 

Rgure 45 DSS Devetopment Platform Environment 

Rgure 46 Generic System Architectura 

Rgure 47 System Architecture in View of the DSS Prototype. 

Rgure 48 The Logon Dialog Box. 
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Figure 49 The Opening Screen of the DSS. 

Figure 50 User Preferences Selection Dialog Box. 

Figure 51 The Select Data Domain Form. 

Figure 52 Edit Data Domain Dialog box. 
5 Figure 53 Make Product Domain Dialog Box. 

Figure 54 Save Scenario Dialog Box. 

Figure 55 Open Scenario Dialog Box. 

Figure 56 Demand Management Bottom Up Forecast Saeen. 

Figure 57 Demand Management, Top Down Forecast Screen. 
10 Figure 58 PronDotion Calerxiar Main Display. 

Figure 59 The Promotion Selection Wizard. 

Figure 60 The Main PS! Frame Form. 

Figure 61 The Options menu choices on the PSI screen. 

Figure 62 PSI RecorKiliation Order Dialog Box. 
IS Figure 63 The main capacity checking dialog box - The Optk)ns tab. 

Figure 64 The Results tab. 

Figure 65 The Production Resource tab. 

Figure 66 The Key Components tab. 

Figure 67 The Bill of Material tabi 
20 Figure 68 The Alternative Components Tatx 

Figure 69 The Resou'ce Requirement tab. 

Figure 70 Key Component Selection Diak>g Box. 

DESCRIPTION OF THE PREFERRED EMBODIMENTS 

2S 

Introduction 

Overview of tfie DSS Conceptual Architecture 

30 The Decision Support System (DSS) 10 of the present inverrtion (see figure 1) relies on quantitative models and 
data analysis routines to provide decision sif)pon Consider for exanrple the production, sales and inventory (PSI) plan- 
ning process. An architecture to provide such si4)port in accordance with the present invention comprises a library of 
models and routines that are logically linked, regularly updated and maintained. To support the PSI planning process 
for exarrple, one can then errptoy an appropriate sut>set of nxxlels and routines from the Ibrary to represent the under- 

35 lying supply cfmin abstraction and provide decision support. The present invention assembles the models and routines 
in a fleidsle manner, as needed k)y a decision making environment, to enable the DSS 10 to provide customized ded- 
6k>n Sif}port with a readily upgradat3le and scalable lit>rary. 

Principal Design Bements 

40 

The architecture of the Decision Support System (DSS) 10 for a manufacturing supply chain is shown in figure 1 
and comprises the principal design elements of: a DSS Database 12 with a Datat>ase Management System (DBMS) 14 
and Supply Chain Informatkm Systems 15, Decision Support Frames 16 which provides the various supply chain view 
points, a User Interface 18, a Model Engine 20 including various Model Engine Utilities (processes) 22 and a Supply 
45 Chain Frame Manager 24. The architecture of the DSS 10 in the context of an equipment repair supply chain is Illus- 
trated in figure 2. 

Salient Features 

50 The DSS architecture comprises two t>asic nrxxJe divisk>ns: the Client Mode 30 and the Server Mode 32. These 
modes can be classified with respect to an implementation of the DSS 1 0 in a supply cfiain. From a design standpoint 
the Gient Mode 30 is the portion of the DSS architecture that is specific and therefore customizable to provide decision 
support for any particular decision process and decision maker. The Server Mode 32, on the other hand. Is the kemel 
of the DSS architecture that remains largely the same across different applications of the DSS 10 within a given sipply 

55 chain. Hence, for a given Implementation of the client-server DSS architecture in a sipply chain, there will be one 
Server Mode 32 and a nurTt>er of Client Modes to provide support for the decision processes. 

As shown in figures 1 and 2 the Client Mode 30 comprises the User Interface 1 8. the Decision Support Frames 1 6. 
and the client version of the Supply Cfiain Frame Manager 24. The Server Mode 32 conprises the Supply Chain Frame 
Manager 24, the system level services, the Model Engine 20, and the DSS Datat)ase 12. The Supply Chain Frame 
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Manager 24, as a partidparTt in both modes, serves to tie the Client and the Server Modes of the architecture together. 

The client-server architecture makes the cverafl design b6&\ extensible (new functionality can be added by custom- 
izing a frame in the Client Mode 30) and scalable (new models and routines can be added to the Model Engine 20 in 
the Server Mode 32). Additionally this design is network^e; one can visualize the Server Mode 32 of the DSS 10 
s hosted by a server workstation in a di^-^erver network while a mnnber of Cb'ent Modes 30 of DSS 10 are hosted in 
the client computers. The layered design of the architecture, in terms of how the principal design elenients of the DSS 
10 are positioned within the architecture, provides a more resOient and stable bacMx>ne for decision support. The high 
level design architecture is independent of any computing and networking platfonm and hence applicable to a variety of 
environments. 

10 The structure maintains the design of the horizontal layers for its key system elements while its functionality s more 
aligned vertically The overall DSS 10 interfaces with the Supply Chain Information Systems 15 through the data 
exchanges between tiiese systems and the DSS Database 12. The DSS 10 has a User Interface 18 to interact with end 
users through interactive and visual data exchange. Thus, the main txxfy of the DSS 1 0 includes the following horizontal 
layers: User Interface 18; Decision Support Frames 16; Supply Chain Frame Manager 24 (Client arxl Server); Model 

75 Engine 20; and DSS Database 12 . 

As prevkujsiy mentioned, tfie atxjve layers of the DSS 1 0 can be partitioned into client and Server Modes. The sys- 
tem layers within the Client Mode 30 serve an interpretive role between the system data arxJ analytic processing sup- 
port and the specifk: end user's decision stf)port needs. Those layers under the Server Mode 32 contain system 
functionalities common to a diversity of users and decision support problems, and usually require more dedicated, 

20 higher performance system processing capabilities. 

To capture and process a user's decision support request, the DSS 1 0 win invoke a vertical decision support thread 
40 going through visual objects of a User Interface 18, decision \oq\c and wtmt-if scenario manager in a Decision Sup- 
port Frame, Supply Chain Frame Managers, models or analysis routines in the Model Engine 20 and appropriate data 
elements in the DSS Datat>ase 1 2. An example of a decision support thread 40 is shown by the bklirectional arrows in 

25 figure 3. 

Relevant Supply Chains 

The detailed discussion and specifications for the Dedsion Support Frames 16 provided in this document are 
30 generic in nature so that the functionality and system features in the resulting DSS 1 0 can cover dedsion environments 
for a diversity of supply chaina The system spedf ications and descriptions in this document address the two distinctive 
supply chains previously mentioned: I. Manufacturing: Rnished goods are produced from raw materials, components, 
and subassemblies using resoirces (ag., humans and machines) distributed to the demand points, and consumed t>y 
the end users. Material flow can t>e characterized as linear. II. Equipment Repair: Failed items are sent to the repair 
35 fadlities, repaired using resources (e.g., humans and test equpment), and restored to usable condition. Material ftow 
can be characterized as reentrant 

Even though a typical manufacturing environment may perform a limited anrKXint of repair operations, such as 
machine maintenance or product service, its resources are predominantiy dedicated to material procurement, finished 
goods production and cfistrftxjtion. In this view, the distinguishing characteristic between the manufacturing and repair 
40 environments is the degree to which the environment focuses on the production of new goods versus the repair of oM 
ones. Cotrpared to the manufacturing supply chain, the equipment repair supply chain has complex reentrant f kwvs, 
while the manufacturing e characterized by the linear material flows from material procurement to final consumption. 

DSS Database 

45 

Overview 

The DSS Database 12 is internal to the DSS 10 inplementation. The main objective of the DSS Datat)ase 12 is to 
support the execution of the decision support functionality of the DSS 10. It contains tfie synthesized data drawn from 

50 a variety of extemal supply chain information sources and Supply Chain Information Systems 15. It may also maintain 
a set of data unique to the DSS 10 but not available in any existing Supply Chain Information Systems 1 5. An example 
of such unique data is the data derived through the analysis of synthesized data. The DSS Database 12 can be inter- 
faced to the Supply Chain Information Systems 15 to retrieve the required data and provide updated data, as needed. 
The Datat>ase Management System 1 4 (DBMS) communicates with the Model Engine 20 to provide the input data, 

55 and update the database 12 based on the output of the Model Engine 20. In gen^l the DBMS 14 does not duplrcate 
the transaction-t>ased functionality that is typk»lly featured in the Supply Chain Information Systems 1 5, unless it is crit- 
ical for dedsion support needs. 
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Data Representation Schenie 

Choosing an approprate data representation is Important to ensure data consistency, and reconfigurability. 

5 Structural Data Representation 

A structural data representation of the data in various data spaces 50, 52 and 54 (see figure 4) is used to nrxxJel 
the efemerrts of the supply chain that are relatively static. Specifying these data elenrtents typically specifies the infra- 
structure off the supply chain. At the highest level off at)6traction. four principal nodes (see figures 5 and 6) in the supply 
10 chain 58 are identified: 

DemarxJ node 59: The customer demarxis are characterized at this noda 

Inventory Node 60: Inventories of key components or finished goods are identified to be at these inventory nodes. 
Production Mode 61 : Production resources (or finished goods supply) are located at production nodes. 
15 Conrponent Supply Node 62: The supply points of key components are characterized at the component supply 
nodes. These structural data elements are spatially distrOxited ak>ng the supply chain 58 (see figure 5). The rela- 
tionship between tftese nodes is preferat3ly modeled in the form of a network. The network cfiaracterization is a col- 
lection of Gnks tfiat connect the principal nodes. A link estat)lishes a k)gical relatk)nship between tm nodes, whk^h 
may have several attributes such as distance betwe^ the two nodes, transportation lead time, etc. 

so 

In greater detaD, the structural data elements and their relatk)nship to the principal nodes are desaibed as fblkiws. 
Key components 63 are supplied by component suppliers 64 tied to specific component supply nodes 62. Production 
resources 65 produce the various products 66. The production resources can be aggregated into production resource 
groups 67, and are located at production nodes 61. Products 66 are the end items that are produced and, based on 

25 their various attnlxites, can be grouped into various product groups 67. These products are stocked at various stock 
locations klentified with inventory nodes 60 and inventory headers 68. Customers 69 can be grouped t>y various criteria 
into customer groups 70 and demand various products. Customers 69 are k)cated at the demand nodes 59. Markets 
71 are defined for a cross^ection of customers and products. 

A similar structire can be provided for the repair cfiain as illustrated in figure 6. 

30 Such a data representation in the form of a network of nodes and the ability to group the various constituent ele- 
ments, provide the f lexitxiity to specify and reconfigure a variety of supply chains. 

Process Data Representation 

35 In adcition to the structural elements, the data associated with the various processes in the supply chain need to 
be represented. These process data elements are relatively dynamk: with respect to time and the associated processes 
transform data related to the varkHJS structural elements. To cfiaracterize the process data, we introduce a few addi- 
tional data structure& 

40 Data Space 

A data space is a fundamental domain to cfiaracterize bask: data elements associated witti the supply cfiain man- 
agement demand, supply and inventory data. The data spaces 50, 52 and 54 tie the structural data to the process data. 
It has three principal dimensions: Product/Corrponent; Time; and Node related structural element. As the node-related 

45 Structural element can be a customer, an inventory kx^ation, or a production resource. The data in each data space can 
be at any resolution (in terms of level of aggregation) atong the three dimensions and can be expressed as a quantity 
or value. Thus, each point in tfie data space cfiaracterizes the resolution off tfie product (or component), the time and 
the node-related structural element. For example, when descrftxng the ag^egate production plan data, a product can 
t}e at the resolution of product, time at a resolution of weeK arxl the node-related structural element (Production 

so resource in this case) at a resolution of production resource group. On tfie other fiarxi, in descrbing bottonvup fore- 
casts, a product can be at the resolution of product, time at a resolution of month, and node related structural element 
at the resolution of customer. 

We identify three principal data spaces associated with supply chain management: Demand Data Space 50; Inven- 
tory Data Space 52; and Supply Data Space 54. These data spaces are pk;torially represented in figure 4 and are 

55 explained next. 

Demand Data Space 50: This data space 50 has three dim6nsk>ns: Customer; Product; and Tima Customer can 
be at a resolution of customer or customer group or demarxl noda Product can be at the resolution of product or prod- 
uct group. Time can be at a resolution of day, week, bi-weeK montfv bt-nxxTth. quarter or year. 

Supply Data Space 52: This data space 52 has the fdkNving three dimensk)ns: Production Resource; Prod- 
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uct/Component; and Time. Production resource can be at a resolution of production resource, production resource 
group, or production node. Product/Component can be at the resolution of component product or product group. Time 
can t>e at a resolution of day, week, bi-week. month, bi-month, quarter or year. 

Inventory Data Space 54: This data space 54 has the following three dimensions associated with it: Inventory Loca- 
5 tion; Product/Conponent; and Tima Inventory location can be at a resolution of stock location or inventory nod& Prod- 
uct/Component can be at the resolution of component, product or product group. Time can be at a resolution of day, 
week, bi-week, nrx)nth. bi-month. quarter or year. 

A decision process relates or transforms data either within a data space or t>etween data spaces. For example, 
ag^egate production planning transforms data from tiie supply space to inventory space and vice versa. We will 
10 employ this data space representation to specify the various decision processes In supply chain management 

The DSS Database 12 comprises structural information (information related to relatively static information such as 
product groips, market groups, supply chain network, etc.). and process information (dynamic information related to 
demand, production plan, etc.). Figure 5. prevfousty discussed, graphically represents the structural data tables for the 
manufacturing supply chain. 

75 Similarty. the DSS Datat>ase 1 2 for the equipment repair supply chain (see figure 6) comprises structural informa- 
tion (information related to relatively statfo Information such as equipment repair resources, supply chain network, etc.), 
and process information (dynamic information related to usage, requirements, repair plan, etc.). Again, tfie structural 
elements are flexit)ly collected into different groups to allow users to analyze data at various resolutions. For exarrple, 
equipment of the same age can be grouped together to analyze the effect of age on repair requirementa Figure 6 

20 graphically represents the structural data tables for the equipment repair supply chain. 

The process data in the DSS Datat>as6 12 are contained in two dosety related table type data structures (see 
t>elow): (I) header file that specifies the resolutions and values on the relevant dimensforis of product, cistonYer, time, 
resource, and item, (ii) corresponding data file which contains the actual data at the resolutions and values specif led in 
the header. The process data are preferably stored In these two tables (Table 2, Table 3). rather than one consolidated 

26 tak}le (Table 1). to avokl redundancy and updating anomalies. A foss-less join of the header arxl the data tables will 
result in the consolidated taSoke (Table 1). The fblkiwing example demonstrates this point 
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Table 1 

A single consolidated table with redimdancy (not in normal form) 
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Table 2 

Header table that provides the series information 
and the various identifiers 



Orientation 


Time 


Quantity 


Header ID 


Period 




1 


8/1/96 


10 


2 


6/1/96 


20 


2 


7/1/96 


30 


2 


8/1/96 


75 


2 


9/1/96 


50 


3 


6/1/96 


12 


3 


7/1/96 


40 


3 


8/1/96 


57 


4 


9/1/96 


50 


4 


10/1/96 


2 


4 


7/1/96 


3 


5 


1/1/96 


40 


5 


2/1/96 


2 


6 


5/1/96 


74 


7 


3/1/96 


3 


7 


6/1/96 


565 


7 


4/1/96 


500 



45 

Table 3 

Data table that contains references to the header teQ>le 

and the time series data 

so 



Data tables 

The data tables In the DSS Database 1 2 are preferably specified as follows: Name of the table; Brief description of 
the data contained in the table; Identifier for the data fields; Type of the data field; and Brief description of the data fields 
(this indudes the choice of values for the data in this field, if applicable). 

The spedfications of the data tables for the manufacturing and equipment repair supply chains can be found In 
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Appencfices A and B. respectively. The list of the preferred tables in the DS8 Database 1 2 for these chains is as follows: 
Aggregate Production Plan Data; Aggregate Production Plan Header; Budget Data; Budget Header; Calendar; Com- 
ponent; Component Acconvnodation Matrix; Component Requirement Data; Component Requirement Header; Com- 
ponent Supplier; Component Supply Contract; Componerrt Supply Node; CPRD Table; Customer; Customer Group; 

5 Customer Group; Definition; Customer Orders; DataFiekJ Ddinition; Demand History Data; Demand Htetory Header; 
Demand Node; Demand Orientation Data; Demand Orientation Header; Domain; Domain D^nition; Feature Choices; 
Forecast Data; Forecast Header; Freight Rate; Inventory Data; Inventory Header; Inventory Node; Inventory Parame- 
ters; Market Data; Market Header; Material Delivery Schedule Data; Material Delivery Schedule Header; Planning 
BOM; POS Data; POS Header; Product; Product Features; Product Group; Product Group Definition; Production 

w Acconrvnodation Matrix; Production Capacity Data; Production Capacity Header; Production Matrix; Production Node; 
ProchJCtion Requirements Data; Production RequirenrYents Header; PronKition Data; Promotion Header; Resource; . 
Resource G^oup; Resource Group Deh'nrtion; Sales Requirements Data; Sales Requirements Header; Scenario; Sce- 
nano Data; Compatbilrty; Scenario Definition; Setup Matrix; Supply Chain Network; Supply Order Data; Supply Order 
Header; Temporary Product List; VMR Contract; VMR Data; and VMR Header 

15 

Core Reports 

The present invention preferably provides core reports that support business decision processes by characterizing 
the link between the various data elements and processes. They synthesize the data and infonmatk>n used in the deci- 
20 ston making processes. Associated with each key business process, we will demonstrate the data f kw relationships 
that are used to coristruct the various fornis and reports. Soine of the prefers 

10 are: Sales Plan; Customer-Demand History; Productk>n-Sales-lnventory Plan; M^ter Production Plan; Production 
Capacity Plan; Replenishment Schedule; Customer-DC Assignment; and Supply-DC Assignment 

25 Decision Support Frames 

Overview 

From a user perspective, a Frame 1 6 is an integrated decision sipport environment based on an abstraction of tiie 
30 supply chain designed to address a set of related decision problems within a decision process. A Frame 1 6 is tiierefbre 
defined based on the vantage point or view point of the users akxig a supply chain. This implies that a frame exists if 
and only if there are users with specif k: needs in the supply chain. 

From a system perspective, a Frame 16 is a mechanism that unifies the user dialog and cfisplay. the models and 
analysis routines, and data in a ntanner that is consistent to support the underiying supply chain abstraction of the user. 
35 A surnnriary of the franie concept from both a i^er and a system perspective is shown in Table 4. 



40 



46 



50 



55 
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User Perspective 


System Perspective 


An environment to address 
a collection of related 
decision problems. 


It is a subsystem that 

- • 

processes user reG[uests xn 
the form of Scenarios. 


Always associated with a 
decision maker or a group 
of decision makers. Frame 
exists if cuid only if 
there are decision makers. 


It consists of a 
consistent set of process 
and data models. 


Has a unique perspective 
of the underlying supply 
chain based on the 
responsibility of the 
decision mcOcers associated 
with the frame. 


It unifies the User 
Interface, Model Engine, 
and DSS Database elements 
that are specific to a 
decision making process. 


Enhamces the coordination 
of decision making 
implicit in the definition 
of the frame. Enforced 
through organizational 
accountcJDility and 
responsibilities . 


A convenient client -server 
architecture that enables 
the extension of the DSS 
functionality. 



Table 4 

Frame Concept: User's auid System Perspective 



30 

Rame Architecture 

The high level design of a Decision Support Frame 16 and its interaction with the User Interface 18. the Supply 
35 Chain Firanie Manager 24, the Model Erigine 20. and the Datak>ase 12 is illustrated in figure 7. A Frame 16/72 is the 
abstraction of the supply chain from a user's point of view. It essentially contains as its design elements a user dialog 
72 and user display 74 and a decision logic 76. The user cBalog 73 and the display 74 contain the form and style of the 
User Interface 18. The decision logic 76 perrrats the assembly of models and analysis routines and the associated data 
to address the set of related decision prot)lems. For example, in the case of the PSI Plannirig Frame 160. the user da- 
40 log 72 and display 74 are customized to the specific needs of the PSI planning process, which further determines the 
design of the User Interface 18 assodated with the PSI Planning Frame 160. Users will interact with the PSI Planning 
Rame 1 60 through the User Interlace 1 8 kiy formulating Scenarios 78. Based upon the Scenarios 78. the decision logic 
76 in the PSI frame may assemble models and routines from the Model Engine 20 along with the associated data. The 
decision logic 76 in a frame interacts with the Supply Chain Frame Manager 24 to execute the models and routines. The 
45 Supply Chain Frame Mariager 24 then provides the performance feedt>ad< to the user. 

Decision Processes in the Manufacturing Supply Chain 

The decision processes in the manufacturir^ supply chain are depicted in figure 8. We have identified five decision 
so processes closely associated with the key decision makers and poterrtial users in a supply chain: Overall Supply Cfiain 
Management 80. Demand Managenmit 81. PSI (Production-Sales-lnventory) Planning 82. Supply Management 83. 
arxJ Vendor Managed Replenishment (VMR) 84. 

Overall Supply Chain Management 

55 

A supply-chain-wkie view arx) the necessary Management 80 is recognized l7y all levels of the management as 
being vital to managing the txjsiness. However, dedson makers at different levels arvi points along the supply chain 
are primarily nKitivated by their individual roles and responsibilities. The broader a decision maker's responsbilities. the 
mae likely the decision rnaker interested in employing decision support capabilities that target the entire sipply 
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chain. The user requirements discussed below lor decision support are posed from a supply-chain-wide perspective. 
Given the uncertainty in the medium- to long-term sales forecasts, determine whether or not the enterprise shouU 
expand, maintain or reduce Its production capacity and/or stocks for the critical components. When changes in txjsi- 
ness corditions impact one part of the supply chain, assess the potential impact on the other parts of the supply chain. 
5 Given different future t>usiness scenarios, determine their financial consequences across the supply chain. For the 
enterprise's supply chain which includes major retailers, determine the appropriate diviaon of responsibflities for ail 
partners in the supply chain. Develop and implement performance incentives that will enhance and encourage supply- 
chairv-wide thinking arxJ decision making in the enterF)rise. 

10 Demand Management 

Demand Management 81 is the process by which the customers' requirements are characterized with the specifi- 
cation of prevailing uncertainty. The process involves the development and maintenance of mecfium-term customer 
(kxjttonvup) forecasts. These forecasts are inrtialty developed in periocfic joint meetings or communications between the 

15 decision makeis of the enterprise and the customers. Sid>sequently, these forecasts are input into the enterprise's sup- 
ply management system to obtain product allocation approval (place-keeping order). As tfie actual purchase orders 
arrive, the enterprise attempts to fulfill the requirements to their customers* satisfactfon. We have klentified the user 
requirements discuss k>ek3w for dectsfon support for this process. Synthesize infornnation from different sources in order 
to manage the demand requirements effectivety, eg., accessing point-of-sales (POS) data and corrparing these with 

20 shipment history arxJ customer forecasts. For key custonYers^devefopcustomer-specifk: sales forecasts bas^ 

torical shipment and sell-through data. Link POS data, wfiere available, to the historical promotion information to ana- 
lyze the real innpact off promotfon activities on demand, as opposed to relying on the estimates provides by the retailers. 

PSI Planning 

25 

PSI Planning 82 is a process to determine a set off feasfole sales, production and inventory requirements for 
medium to long-term capacity and resource planning for the logistkx operations. At the beginning off each fiscal year, 
an initial PSI plan can be developed based on the long-term top-down sales forecast and budget plans. The planning 
process then becomes a continuous effort to update the existing PSI plan to acconvnodate the changes in the require- 

30 ments before and after a series off monthly PSI planning meetings whose partk:ipants include decision makers repre- 
senting all key functkxial areas at the enterprisa The meetings inte^-ate the inputs from various sources, resolve 
possible conflk;ts, and balance the concerns of different functfons in order to reconcile, develop and approve a new set 
off feasible sales, productfon and inventory requir^nents. The process represents a focal point for the entire logistics 
planning process, and interacts and coordinates with all major dedsfon making processes. We have identified the user 

35 requirennents discussed k)ek)w for dedsfon support for this process. Generate n^^ 

gories for the enterpr^ as well as the entire inc&istry. Such forecasts will be based on availat)>e shipment history, indus- 
try survey data arxJ influential ecor)onrtic indk^ators. Generate forecasts for new products and managing product 
transrtfons. Fadlitate devefopment of medium-term top<icwn and bottom-up sales forecasts for the enterprisa Facilitate 
development of production plans and the associated requirements plans for critical components. Evaluate the effects 

40 and understand the implk;ations off spedffo changes in the sales or productfon plans. Conflkrt resolution mechanisms 
are needed to adapt and maintain these plans. Mentify ttiose products that woufo be affected by the shortage of certain 
critk:al components; one possfole approach is to use an impfosfon tool on the bill off materialSw Provide a fornDal mech- 
anism to determine and reacijust appropriate inventory levels for various products. 

45 Supply Management 

Supply Management 83 is a process to determine the production (supply) plan to meet the production (supply) 
requirements generated t>y the PSI Planning process. The process involves component procuremerrt and factory pro- 
duction planning k>ased on the PSI plans and their changes. At the beginning off the process, the production line capao- 

50 ities are created based on fong^erm product plans, i.e., planned new product releasa The process continuously 
updates the production (supply) plan based on changes in the production (supply) requirements generated in the PSI 
process. We have identified the user requirements discussed bekw for decision support for this process. Deterrrtine the 
feasitMlity and the economic viatMlity of chariges in the production (supply) plan, when changes occur in the PSI plans. 
This requirenDent is motivated by trade-offs between the PSI process arxi the production (supply) planning process. 

55 Evaluate possit>le options to accommodate changes in the production requirements, after the line structure and capac- 
ity are determined. Such an analysis is a requirement of the factory planner. Devefop an aggregate level representation 
off the production line capacities so as to help the planners in developing aggregate production plans or checking pro- 
duction capacity Develop a rough-cut analysis capability to assist the planners in translating the production require- 
ments into critical component requirements, i.e.. corrponents featured in the planning k>ill of materials. 
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Vendor Managed Replenishment (VMR) 

VMR 84 is a process in which the supplier takes on the responsibility of managing the inventory at the customer 
site for the products It supplies. TTus process operates on point-of-sales demand as opposed to demand forecasts pro- 

5 vided by the customers. VMR involves fbnmilating the contractual agreements t>etween the errterprise and the retailers 
as well as determining the operating parameters such as shipment quantities and replenshment frequ&ides. We have 
identified the user requirements d'^cussed below for decision support for this process. Develop a strategic analysis tool 
to determine mutually beneficial VMR contracts based on financial and logics factors. Develop the replenishment 
plan based on factors such as sen-through arxJ inventory information provided by the retailer, pronruition activities, prod- 

10 uct availability and transportation cost trade-off& 

Decteion Processes in the Equipment Repair Supply Chain 
Overview of the equipment repair supply chain 

75 

The equipment repair supply chain 90, as depicted in figure 9, includes the operating location 92, i.e., the point-of- 
use. the repair shop 94, and the component suppliers 96. In an equipment repair supply chain, the demand (or the 
'requirements') are generated equipment failures. When equipment fails, the failed nxxiule is replaced from the 
stock at the operating focatkxi 92. and tfie tailed module is eventually sent to the repair shop 94 for repair. A module is 
20 rT^ei4>of repair itennswNch in turn are nriadei4> of corrponents. At the repab 

repair resources (people and machinery). During the repair process at the repair shop 94, certain repair items and com- 
ponents are replaced. Based on the repair needs, repair items and components wai be ordered from the sources of sup- 
ply by the repair shops. 

Equipment Operating Location 92: At the equipment operating tocatfon 92, personnel may replace only certain 
25 repair items of the module, instead of the wfwie module These replacement repair items may come from the stock or 
from other failed nvxlules. This process encourages consolidation of failed modules at the operating focation. In the 
corisolidation process, the broken repair item of a broken niodule is replaced by a good repair ^ 
module. This process may t>e motivated by the structure of the repair cost function and the need for quick repair. In 
some cases, due to the fixed costs of serxjing indivkiual modules to the repair shop, modiies are batched to a certain 
30 level, before th^ are sent to the repair shop for a complex overtiaul. 

Repair Shop 94: The repair shop 94 is responsible for all the major repairs. The type of repair to perform is driven 
by the level of good modules at ttie repair location. When good modules are sent from the repair shop to the operating 
location, the stock level may drop t>ek3w the target level, thus triggering a repair request to bring the stock level up to 
the target level. This target level is determined with the objective of maximizing the equipment availability and minimiz- 
35 ing the repair costs. Component and capacity requirements corresponding to a repair request should t>e feasit)le wfth 
respect to component availability and resource capacity levels at the repair shop. 

Parallel with the manufacturing supply chain: 

40 We recognize the operational differences between manufacturing and equipment repair supply chains. However, 
the equipment repair supply chain has dear parallelism with the manufacturing supply chain where the repair items cor- 
respond to products and components correspond to nriaterials. Equipment operating focations are similar to retailers 
and equipment is like customers. The repair shop is anafogous to a production facility. As modules are made up of 
repair items, modules correspond to product g-oups. The repair reqiirements management process is anafogous to 

45 demand management, and repair supply management to supply management Similar to the PSI process, there exists 
a reconciliation process in the equipment repair supply chain to ensure t>alance t>etween requirements and sipply. 

Application to a natior>al defense application 

50 For a national defense application, the follcwing nomenclature is used. The equipment located at various operating 
locations are the aircraft operating at the various bases. The modules con-esporKl to the Line Replaceable Units, or 
LRUs and the repair items correspond to Shop Replaceable Units (SRUs). The failure of an LRU, caused by the failure 
of its SRU, renders the aircraft unavailable. The function of the base is to provide inrvnediate support to the aircraft 
located at that base, with the objective of maximizing availability of aircraft For that purpose, bases stock good units of 

55 replaceable items, called serviceables, so as to t>e able to replace a failed LRU of an aircraft immediately. A t>ase, usu- 
ally, is not inM)lved in major repairs. Instead, it implements a consolidation policy (replacing the defective SRU of a 
newly failed LRU with a good SRU of an already d^ective LRU), which gives the base the ability to manage the repair 
requirements of the depot Managing the repair requirements refers to deckling when ond whfoh defective items the 
base will send to the depot for repair with the oksjective of maximizing the availability of aircraft focated at the base and 
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minimizing total cost of repair (wtiich irKludes a fixed cost component). 

A depot is responsS)le for all the major repairs. The type of repair to perform s driven t3y the le/el of good repairable 
items at the depot When good repairat)le items are sent from the depot to the base, the stock I wel may drop below the 
target level, thus triggering a repair request to bring the stock level up to the target level. This target level, also called 
the Consolidated Serviceat)le Inventory (CSI) level, is determined by the depot with the objective of maximizing its serv- 
ice level and minimizing its repair costs. Component and capacity requirements corresponding to a repair request 
should be feasftile with respect to conrponerrt availabifity arxJ resource capacity levete at the depot 

Table 5 below presents the analogy and nomenclature between the equipment repair supply chain, and the manu- 
facturing supply chain with examples from defense and comoYercial environments. 



Equipment 
Repair Supply 
Chain 


Example 
Defense 
Equipment 
Repair Supply 
Chain 


Example 
Commercial 
Equipment 
Repair Supply 
Chain 


Parallel with 
Mcunufacturing 
Supply Chain 


Equipment 


Aircraft 


MRI Machine 


Customers 


Module 


LRU 


Cabinet 


Product Group 


Repair Item 


LRU / SRU 


Circuit 
Boards 


Product 


Component 


Bit and piece 
part 


IC 


Component 



Table 5 

Analogy and nomenclature between equipment 
repair and manufacturing supply chains 



Decision Processes in the Equipment Repair Supply Chain 

The supply chain comprises (see figure 9) the follcwing three dedsion processes: Requirements Management 
Process 98; Requirements-Sippty Reconciliation Planning Process 100; and Supply Management Process 102. 

Requirements Management Process 

The Rec^irements Management Process 98 concentrates on the activities associated with requirements estima- 
tion. The ot)jective of this process is to estimate future repair requirements generated l)y equ^>ment failures. Equipment 
has several repairat)le parts and equipment failures are caused by failures of the repairable parts. Hence estimating 
future requirements refers to the process of estimating failures of the equipment and of the repairak)le parts that caused 
the failures. This is done to estimate repair time requirements (determined in Requirements-Supply Reoondliation 
Planning Process) and equipment availability at equipment locations, both of which depend on the part that has failed. 

Requirements can be analyzed in two levels: Lower level requirements, called the Raw Requirements, correspond 
to all repair requirements of the equipment and upper level requirements, called the Consolidated Requirements, cor- 
respond to requirements requested from the repair shop, since equfxnent locations may prefer accumulating their 
repair requirements and sending them to the repair shop accorcSng to certain rules instead of sending them as th^ 
occur, or may prefer carrying out minor repairs within the location, with the aim of redudng the fixed and variat>le costs 
of repair. In the manufacturing analogy, raw requirements would corresporxJ to Point of Sales (POS) data and consoli- 
dated requirements to retailer order data from the production facility. 

Two differerrt estimation approaches that have t>een used in this process to estimate consolidated requirements 
are: Bottonvip Estimation Approach; and Top^icwn Estimation Approach. 

The bottonfHjp estimation approach estimates the raw requirements first and then generates the consolidated 
requirenients from raw requirement estimates. In order to estimate raw requirements, relationships are determined 
k>etween failure rates and activity schedules of the equipnvent For example, the time to failure of an equipment can be 
a furK;tion of tfie number of hours it has operated and its maintenance schedJe. Once the relationships between failure 
rates and activities are established by regression or time series nKxjels. future failure rates can k>e estimated based on 
the planned activity schedules of the equipment G^en tfie estimated raw requirenr>ents, the next step is to go to the 
upper level arxj estimate consolidated requirements, that is requirements as seen by the repair shop (assuming that 
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repair shop does not have access to raw requirements data). Consolidated requirements depend on what frequency the 
operating location will serxi its repair requests to the repair shop. This is analogous to the inventory replenishment pol- 
icy of a retailer in a manufacturing system. In deckfing on the type arx) parameters of the inventory replenishment policy, 
the facOrty will use several conflicting performance measures such as minimizing total repair cost and maximizing avail- 
ability of the equipment Thus, given the Inventory replenishn^ policy of the facility and estimates of its raw require- 
ments, Its consolidated requirements can be estimated. 

The top-down estimation approach makes use of historical data to estimate consolidated requirements. Statistical 
forecasting techniques can be used to support this process. 

The two estinrtates obtained t>y bottonrHJp and topdown approaches are compared, analyzed and reconciled to 
generate final estimates for cor^ldated repair requirements. The output of this process is the estimated consolidated 
rec^irements for an equipment operating location. 

Requirements-Supply Reconciliation Planning Process 

The second process is the Requirements-Supply Reconciliation Planning process 100 that aims at developing an 
integrated repair plan for the repair shop through a reconcfliation process. Rrst, the type and paranDeters of the repair 
policy of the repair shop are to k>e determined. Aggregate repair reqiirements are generated based on the repair policy 
of the repair shop arxi estimated consolidated requrements for all factlities. The next step is to generate an aggregate 
repair plan based on repair time estimates for each repairBk)le part and the aggregate repair requirements. Fea8S>ility 
of tiie aggregate repair plan is checked with respect to resource constraints which are repair resource capacities and 
k^ component availat}ilrty. If the agg'egate repair plan is rK3t feasible with respect to resource constraints, then causes 
for infeasibillty are Identified arxJ the irrfeasibility is renrxsved by either changing the level of the resource constraints or 
moving ag^egate requirements forward or backward in tima This procedure is repeated until an aggregate repair plan 
that is feasible with respect to resource corrstraints Is attained. The supply managennent 1 02 (see figure 9) is a process 
to determine the repair plan considering repair people, test equipment av6 key components. It starts by the trar^ation 
of the aggregate repair plan Into a detailed plan concerning repair resources (repair persons and test equipment), and 
conrponent requiren>entSw Based on these requirements and the capacity coristraints for the repair resources, repair 
personnel and key components, a detailed repair plan is devek)ped using an optimized based nxxJeling approach. The 
detailed repair plan is used to generate the key component delivery schedule to be transmitted to the component sup- 
pliers. In addition, the supply management process 1 02 is also concerned with the devek)pment of appropriate procure- 
ment polkaes for key components in temrrs of identifying the policies, and derivirig the corresponding pdcy parameters. 

Bask: Frames 

The bask; Frames 1 6 of the present invention collectively provkie coverage for the overall supply chain. The specific 
instances of these Fran^ 16 in a particular DSS 10 implementation depend largely on the constituent supply chain, 
the urxf eriying business processes, and the organizational structura Table 6 bekTw lists the Dectsk>n Support Frames 
16 in the context of manufacturing arxJ equipnnent repair supply chains. 
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Manufacturing Supply Chain 


Equipment Repair Supply 
Chain 


Demand Management 


Requirements Management 


PSI Planning 


Requirement 8 -Supply 
Reconciliation 


Supply Management 


Supply Management 


Vendor Managed 
Replenishment 




Finished Goods Distribution 
Network Design 





Table 6 

Decision Support Frames in the Context 
of Manufactiiring and Equipment Repair Supply Chains 



25 Specificatbn of the Baste Frames 

To specify each basic Frame 16, we use influence diagrams to map the modules in the Model Engine 20 and the 
Data Spaces to the frame. We use process flow diagrams to outline the high level design of the logical relationship 
among tfie key data tables, the modUes and the basic Frames 16. We also discuss hew to stpport key furK;tional 
30 requirements in each frame. To complete the specification of the basic Frames 16. we use data fbw diagrams to map 
the data tables to the core reports In each fFama The legend for the process and the data flew diagrams which will t>e 
discussed herein after is shown in figure 10. 

Demand (Requirements) Managennent Frame 

35 

The Demand Management Frame 130 supports the demand management decision process descrbed here. 

Manufacturing Supply Chain 

40 Module and Data Space Assodatbn 

Figure 1 1 shows the partk^ipating modiries and the associated data spaces for this frama 
The Demand Management Frame 130 requires the partk;ipat'on of two modules: the Sales Forecasting and Plan- 
ning (SFP) Module 132 and the Market Data Analysis (MDA) module 134. The SFP Module 132 in the Demand Man- 
45 agement Frame 1 30 essentially operates in the D data space, Le.. it transforms data within the conceptual demand data 
domain. The MDA Module 134 in the Demand Management Frame 130 operates in the I and the D data spaces and 
relates the I data space to the D data space, i.e., it may transform data within the individual D data space as well as 
transform data from the I data space to the D data space. The data space representation of the Demand Management 
Frame 1 30 is the union of the data space representatfons of each partk;ipating rrxxlule, and the interactions anrx)ng par- 
so tfoipating modiJes. 

The high level representation of figure 11 can be corrplemented by the process flow diagram for this frame, 
described next, tftat will detail the connectfons between the constituent modules and the associated data tables. 

Process Flow 

55 

The process ffow dagram for the Demand Management Frame 130 is shown in figure 12. The modules, data 
tables, arvl the principal activities within the scope of this frame are dearly marked t)y the grooved double-lined tx)rder. 
Only the data tables that are updated by the frame are consktered to be within the scope of the frame 130. Other 
frames, activities and data tables that are related are also shown for corrpleteness. The Order Fulfillment 149, that is 
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out-of -scope of the Demand Management Rame 130 but related to rt. is shown separately in figure 13 ibr purposes of 
clarity. This representation of interaction between Frames 16 is consistent with the interaction between decision proc- 
esses shown in figure 8. 

The DemarKi Management Frame 130 sijf)ports the functional requirements described loelow. DemarxJ Character- 
5 ization - Demand data from various sources such as Demand History Data 136. POS Data 138, Market Data 140. and 
Promotion Data 142 as well as top^jown and bottom-up Forecast Data 1 46 obtained by buyers and account managers 
wiD t>e consolidated and synthesized by the MDA Module 134 and the SFP Module 132. Bottorrt-up DemarvJ Forecast- 
ing - Demand Review 144 consolidates demand irrformation received directly from the customer along with the input 
from the MDA Modide 134 and then develops Demand Orierrtation Data 148. The SFP Module 132 will then use 
10 Demand Orientation Data 148 as well as other inputs, ag. Promotion 142 and POS 138 Data, to develop the customer- 
centric bottom-up forecasts in Forecast Data 146. Top<town Forecasting - The SFP Module t32 will use market and 
industry-wide trend analysis performed by the MDA Module 134 ak>ng with the enterprisers shipment history to gener- 
ate the product-centric top-down forecasts in Forecast Data 146. Sales Promotion Analysis - The MDA Module 134 
renews the demand history from POS Data 138 and Demand History Data 136 along with the customer promotion 
15 information from Promotion Data 142 to analyze the impact of promotions on salea The results of such an analysis are 
then used to help adjust sales forecasts to account for prornotiorrs. Forecast Performance Evaluation - Using Demand 
Orientation Data 146, Demand History Data 136 and Promotion Data 142, tfie SFP 132 and MDA Module 134 can eval- 
uate the quality of enterprise's forecasts and the customer projectkKis. 

20 Data Flow 

The data flow da^am for the Demand Management Frame 130 is shown in figure 1 4. The Demand Management 
Rame 1 30 generates two of the core reports listed eariier, namely, the Sales Plan 1 52 arxJ the Customer-DOTfiand His- 
tory 1 54. For each core report, the associated data tatHes are shown. The dashed line indicates the influence of an out- 

25 of-scope (with respecttotheDernandMariagemerrtFrarne 130) data table in the developnrierit of the For exam- 
ple, the Customer Orders data table 150 is out-of-scope of the Demand Management Frame 130 but irrfluences the 
Customer-Demarxf History report 152. 

Demarxi Mar^agement is the process in which the user determines future requirements t>ased on past requirement 
history and general information related to the supply chain. In the context of the manufacturing environment Demand 

30 Management supports the analysis of past demand and of market trends as well as the development of future forecasts. 
For the repair environment the term Requirement Management is used in place of Demand Management Requirement 
Management is the process where future requirements are estimated based on an analysis of each equipment's activity 
and on the projection of past requirement history. 

In the manufacturing context, DemarxJ Managenrient regx)i4)s the set of processes t>y which the user analyzes 

35 Market Data 140 and past demand history for the purpose of estimating future demarxl requirements. The outputs of 
DemarxJ Management ir^dude the analysis of past history, futLre forecasts, the analysis of special activities such as 
sales pronwtbns, and the ar>alysis of forecast errors. Two critical outputs of Demand Marmgement are two different 
medium term forecasts corresponding to two cfifferent views on the dynamks of the processes tfiat generate future 
rec^irements: the customer centric forecast - generated at the product level for each customer it incorporates the esti- 

40 mations of future demand provkied by each custonDer (Bottonvup ForecasI}; and the product centric forecast - gener- 
ated at the product level, it incorporates the inpact of market and industry-wkle trerxte on future demand for each 
product group (Topdown Forecast). These two types of forecast are generated using: Historical projection of past 
demand; Future orders inforniation; Armtysisoftfiedyrianik^sandcharacterislKSOf thec^ com- 
petitors; and Analysis of the impact of future special commercial activities such as sales pronrxitions. These analyses 

45 and prpjectfons are grouped in five functfonal requirements that are detailed in the rest of this section: DemarKJ Ctiar- 
acterization. BottonrHjp Demand Forecasting, Top-down Demarxi Forecasting, Sales Promotion Analysis, arxJ Forecast 
Performance Evaluation. 

Other frames such as production, sales arxl inventory (PSQ or vendor managed replenishment (VMR) may directiy 
or indirectty use the output of Demand ManagenDeni 

so 

Demand Characterization 

The objective of Demand Characterization is to provide the user with an environmerrt where (s)he can access, ana- 
lyze and synthesize demarxi data from different sources. These data include: Sales History data (tfiat include POS and 
55 shipment data). Inventory data (relative to the inventory position of its product at the customer's stocking points), and 
Market Data 140. Market Data 140 corresporxi to various quantitative information, usually provkied by external entities 
such as Nielsen, that relates to the sales for the type of product consklered in the entire mari^. 
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Acquire, Display. Ecft Data 

Data Acquisition consists of selecting a Data Domain (specific pairs of customer and product), and choosing Itie 
type of data to be displayed (POS. demand history, inventory, Market Data 140). Data can be edited and modified and 
saved along with results of analysis in a scenaria 

Analyze & Synthesize Data 

Sales History and Customer Inventory Data 

Th^ involves the operations discussed t>elow. 

Compute, display (tables and graphs), characterize and analyze sales history per product/product group or cus- 
tomerAxistomer groijp (see the MDA Module specification dscussion for detaite of nrxxjels and formulas): Volatility of 
denrtand, Lumpiness of deniand. Trends in demarxJ history, Demand pattern chariges, arxl Seasonality. 

Compute, display (tables and graphs) arxl analyze sales hi^ory statistics for different levels of aggregation: This 
year vs. last year. Actual sales vs. budget, and Year to date vs. balance of Year. 

Compute, cfisplay (tables and graphs), arxi analyze trend in Demand Product Mix by product groip. 

Pareto analysis of sales (or inventory) to identify ABC classification for products (see MDA Module specification 
details of fbmrulas). 

Compute and analyze correlation between the demarxl for (Afferent product g^oips. 

Corrpute. dsplay (tat)les and graphs), and cmalyze new products and nxxlel change-over proffles. 

Compute, dsplay (tat)les and graphs), arxl analyze inventory profile per customer. 

Compute, display (tatiles and graphs), and analyze trade irrventory comparing POS and shipment data. 

Market Data 

This operation involves the operations discussed t>ek>w. 

Display (tak)les and graphs) Market Data 140 (volume, value, market share) by product group; region, or customer 
group (Nielsen, EIA. etc.). 

Compute, display (tatsles and graphs) and analyze Market Data 140 statistics for different levels of aggregation: 
This year vs. last year. Trend, Actual statistics vs. budget assumption, and Seasonality. 
Pareto analysis of competitors (value arxl volume). 
Create price information: list of competitor products per price ranga 

Bottom-Up Demand Forecasting 

The objective of the Bottonvup forecasting is to devek)p a customer specifk; sales forecast based on historical ship- 
ment to the custOTDer, POS information at the customer kx:ation, arxl the customer's own forecast regarding its future 
orders. 

Acquire. Display, Ecfit data. 

Data Acquisition consists of selecting a data Domain (specifk; pairs of customer and product), and ctxx>sing the 
type of data to be displayed: shipment or POS (when available). 

Forecasts gerierated in the Bottom-up forecastir^g frame can be saved t>ack to the OSS Datat>ase 12 or altema- 
tivety saved as scenario. 

BottOTTVup (BU) Forecast generation 

This operation involves the operations discussed bekw. 

Input and maintain customer orders: Forward orders, and Orierrtation orders. 

Choose model for statistical forecast 

Generate and display (tables and graphs) statistical forecast at different level of aggregation (POS or Shipment 
data): Customer group, Individual customers for all products, arxl Individual customers for each product. 
Support integration in BU forecast of expert kncwledge for optimistic/|3essimistic forecast 
Formulate disaggregation togic of BU Forecast at customer level onto products. 
Incorporate impact of future pronxitions for customer specific promotions. 
Compute, cfisplay and edit seasonality factors. 
Review actual seasonality against planned and "company** seasonality. 
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Disaggregate yearly forecasts onto each period using seasonality factors at different levels of aggregation (POS or 
Shipment data): Customer group, Individual customers for all products* and Individual customers for each product. 

Conrpute and cfisplay (tat)les arxJ g'aphs) sales and forecast statistics: Moving average. Year to dateA>alar)ce of 
year, This year vs. last year, and Actual/forecast vs. Budget 
s Support corrparison of POS and Shipment data for analysis of change in trade inventory prof ila 

Invoke forecast accuracy estimation routine. 

Top-Down Forecasting 

10 The objective of the Top<icwn forecasting is to develop a product centric sales forecast based on historical demand 
data and industry artatysis that accouits for market-wide trends. 

Acquire. D^lay, Ecfitdata. 

75 The data Acquisition consists of selecting a data Domain (specifk; pairs of custonner and product), and choosing 
the type of data to t>e displayed: shipment or POS (when available). 

Forecasts generated in the Top^Jown forecasting frame can be saved t>ack to the DSS Datat)ase 1 2 or alternatively 
saved as a scenaria 

20 TopKk»vn (TD) Forecast generation 

This operation involves tfie operations discussed t>elow. 
Choose HfKxiel for statisti cal forecast 

Generate and display (tak)les and graphs) statistical forecast at different level of aggregation (POS and Shipment 
25 data): market level, product group level, and product fine level. 

Incorporate irviustry trend analysis devek3ped in Demand Ctiaracterization in TD forecast. 
Formulate disaggregation logic of TD Forecast at product level onto customers. 
Incorporate inpact of future product specific pronnotiorts. 

Conpute and display (tat)les and graphs) sales and forecast statistics: Moving average. Year to date/t)alance of 
30 year. This year vs. last year, arxJ ActuaUforecast vs. budget 
Compute, display and edit seasonality factors 
Review actual seasonality against planned and "company" seasonality. 

Disaggregate yearly forecasts onto each period using seasonality factors at different levels of aggregation (POS or 
Shipment data): market level, product group level, arKi product line level. 
35 Support forecasting of model change over, arxl introduction of new products. 
Invoke forecast accuracy estimation routine. 

Sales Promotion Analysis 

40 The objective of Sales PronrK^tion Analysis is to analyze the impact of pronrwtional activities. It entaBs maintaining 
the pronrK>tion calendar, estimating the impact of future pronrKitions and assessing the effect on sales of past pronrK>- 
tional activities. The promotion calendar is a table in which the various characteristics of past and future promotions are 
recorded. The knowledge arxl insights gained in sales promotion analysis are used in adjusting bottom^ and top- 
down sales forecasts. 

46 The functional features associated with Sales Pronrxition Analysis are given t>ek)w. 
Maintain Promotion Calendar arxl add new pronrxstions: Ttwe period of pronrxition. 

Type of pronrx3tion (defined by who initiates the pronrxition: firm, retailer, competitor), arxJ Class of pronrv>tion 
(defined by the nature of the promotional activity). 

Intensity of pronation: Search arxJ sort promotbn calendar, and Analyze Past PronrxitbnSw 
50 Display sales data atong with information of pronrxytions under consideration. 
Establish profile for the inrpact of the sales pronfx>tions. 
Analyze pronrx3tion(s) effect through regression or time series nxxiels. 

Partition sates: Display actual sales attributable to normal sales, seasonal effect and promotion effect. 
Plan Future Pronrxytions. 
55 Add pronrK)tion in pronrxytion calendar - specify type, dass, intensity and time period. 
Estimate irrpact of future pronrxytion based on the impact of similar past promotions. 
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Forecast Performance Evaluation 

The objective of Forecast Performance Evaluation Is to assess tfie accuracy of past sales forecasts. Forecast accu- 
racy Is an importarrt measure fa several purposes: 
s tt helps the user to refine the forecasting process by providing feedback on the at)ility of different models and 
approaches to forecast future demand; 

It provides a measure of demand variatMlity tfiat is used to assess necessary safety stock; and 
It guides attention to those products and customers for which demand is difficult to forecast and that require special 
attention. 

10 Two types of forecast perbrmarKe evaluations are considered: forecast accuracy of one particular version of the 
forecast and average accuracy of n periods ahead forecast 

The first faecast performance type provides point estimations of forecast accuracy, whQe the second one is an 
average estimation of the accuracy as a function of the nmnber of period in advance a forecast is produced. 
The fuK^tionai features associated with Forecast Performance Evaluation are given bekwv. 
75 Select data domain. 

Compute and dsplay Forecast errors for: Bottom up forecast Top down forecast arxi Sales plan (invoked from 
PSI). 

Maintain Accuracy Matrix for each type of forecast (table of the forecast accuracy n periods afiead). 
Generate exception report based on level of forecast error for different level of aggregation. 

20 

Equipment Repair Si^iply Chain 

In the context of the Equipment Repair Sijf)pty Chain the term "Requirements Management" is used in place of 
"Demand ManagemenT to indicate that equipment generates "repair requirements" when it breaks down. 
25 Requirements Management is the process of estimating the future requirements of reparable items at the equip- 
ment location. This process can t>e divkied into two main sut>-processes: 

Evaluation of the raw requirements for each equipment; and 

Estimation of the consolidated requirements at the level of each location (several pieces of equipment can t>e 
30 located at the same kx:atk>n). 

These two approaches can be used to estimate future consolidated requirements. 

Bottonvijp m^hod: This approach uses a conrt)inatk>n of two models: (1) the first model estimates the raw require- 
ments of an equipment by modeling its failure rate as a function of the equipment's activity (or usage) and (2) the sec- 
35 ond nrxxlel estimates the consolidated requirement based on the raw requirements and the consolidatkm policy. 

Top dcwn method: This approach Is t>ased on the projection of histork:al data for the consolkiateddeniand. To sup- 
port the two different approaches the functional requirements detailed below have been defined. 

Activity tracking for raw requirements estimation 

40 

This involves the operatx>ns discussed below. 
Select and Display Activity Data. 

Maintain Future Activity Data: Planned Equipment upgrade/maintenance schedules; and Planned Equipment 
usage schedules. 

45 

. Analyze Past Activities 

Review activities: Display historical raw requirements data along with activity data. 
Assess impact of past activities using regression or time series models. 
50 Per type of equipment 
Pertypeof aclivfly. 

Relate future raw requirements to planned activities. 

Use models of past activities to project the effect of future activities. 

55 Consolidated requirements estimation based on raw requiremerrts (bottom-up) 

This operation involves the operations discussed t>ek7w. 
Select and Display Consolidated Requirement data. 

Formulate, and refine consolidation policy (see SFP Module for explanation regarding consolidation policies). 
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Evaluate cfifferent consolidation policies based on past raw requirements. 
Estimate future consolidated requirements based on chosen policy. 

Consolidated requirements estimation based on historical data (topdown) 

5 

This involves the operations discussed t>elGw. 
Select and E)isplay Consolidated Requirement data. 

Choose model for statistical forecast off future usage per repair it^rVlrepair item group. 

Kalman RIter based algorithm for requirements estimation (considered appropriate for forecasting equipment faO- 
10 ures). 

Other sta tis tical forecasting techniques. 

Generate avd display (tables and graphs) statistical forecast at different level of aggregation: Repair item group. 
Incfividual Repair item for all equipment and Individual Repair item for each equipment 

Compute and display statistics (tables and graphs) for actual and estimated consolidated requirements: Mcving 
15 average. Year to date/t>alance of year. This year vs. last year, and Actual/forecast vs. Budget. 

Develop d^ggregation logic off consolidated requirements estimation Forecast at repair item 9-oip onto individual 
Repair item. Users can ovenide algorrtfim based estimates. Requirements reconciliation and requirements plan gener- 
ation 

Th^ operation involves the cperations discussed below. 
20 Corrpare arxi analyze top<iown and bottonvup requirements numerically and visually. 

Reconcile the top-dcMvn and bottonrH^) requirements to generate the requirements plan. 
Use weighted average models. 
Incorporate user*s input arxi cverrida 

25 Requirements estimation performance evaluation 

Store top<lown. bottom-up and reconciled requirements estimateSw 

Compute and cfisplay Estimation errors for: Bottom up requirentent estimation. Top down requirement estimation, 
and Reconciled requirement estimation. 
30 Maintain Accuracy Matrix for each type of requirentent estimation (table of the accuracy n periods ahead). 
Generate exception report k>ased on level off estimation accuracy for cfifferent level of aggregation. 

Production-Sales^tnventory Planning (Requirements-Supply Reconciliation) Frame 

35 The PSI Plannirig Franie 160 supports the PSI planning decision process described here. 

Module and Data Space Association 

Figure 15 shows tfte participating nrxxilules arxJ the associated data spaces for this frame 
40 The PSI Planning Frame 160 requires the participation of three nxxkiles: the Sales Forecasting and Planning 
(SFP) Module 132. the Aggregate Production Planning (APP) Module 162. and the Rnished Goods Inventory Manage- 
ment (FGIM) Module 164. The PSI Planning Frame 160 as a whole involves S. I. arxi D data spaces with iterative data 
transformations amortg each pair. 

45 ProcessRow 

The process flow diagram for the PSI Planning Frame 160 is shown in figure 16. The PSI Planning France 1 60 sup- 
ports the following functional requirements identified for the PSI planning decision process: 

50 Forecast Reconciliation 

The Demand Management Frame 130 supplies the Forecast Data 146 (bottom-up and top-down forecasts). The 
PSI Reconciliation Activity 170 in concert with the SFP Module 132 revises tiie top-down forecasts and reconciles the 
kxyttonvup and top-down forecasts. This is an iterative process which is shown as the '^S** loop (m the top right quadrant 
55 ) in the process flow diagram. If any changes to the bottom-up forecasts are warranted, the PSI Planning Rame 160 
interacts with the Demand Management Frame 130 to make the necessary changes. 
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Inventory Planning 

The PSl Recondltation activity 1 70 in concert with the FGIM Module 1 64 determines the inventory requirenients in 
an iterative tehion. This is shown as the '^r loop (in the top left quadrant) in the process flow diagram. The inventory 
5 requirements are written to Inventory Data 182. The FGIM ModiJe 164 as part off the PSl Planning Frame 160 also for- 
mulates the finished goods inventory policies; the policy parameters are written to Inventory Parameters 1 72. 

Supply Requirement Planning 

10 The PSl Reconciliation Activity 170 in concert with the APP Module 160 determines the production requirements 
that are consistent with the sales plan and the inventory requirements in an iterative fashion. This is shown as the "P" 
loop On the bottom right quadrant) in the process flow diagram. The production requirements are written to Production 
Requirements Data 174. The APP Module 160 as part of the PSl Planning Frame 160 also checks aggregate produc- 
tion capacity and key component availabiBty using Production Capacity Data 180 and Inventory Data 182 (component 

15 availability). 

Production-Sales-Inventory-Plan Coordination 

The PSl Reconciliation Activity 1 70 interacts with the APP Module 1 60. the SFP Module 1 32, and the FGIM Module 
20 164 to coordinate the integrated production-sales-inventory planning. This involves the evaluation off various plan 
options, checking the consistency of the constituent plans and resolving conflicts, if needed. 

DataFtow 

25 The data ftow dagram for the PSl Planning Rame 1 60 is shown in figure 1 7. The PSl Planning Frame 1 60 gener- 
ates the Production-Sales-Inventory Plan report 190 listed earlier. 

The Production-Sales-Inventory (PSl) Planrvng is a process to reconcile demarvl and supply requirements in a 
supply chain. In the manufacturing environment, the PSl Plannirig Frame 160 helps to recorKile production, sales arxJ 
inventory requirement disaepandes. In the repair environment ttre requirements-supply reconciliation helps to reoon- 

30 cOe requirements and supply. 

Manufacturing Supply Chain 

The PSl Piannirtg Frame 160 supports the process that develops an integrated productior>-sales-inventory plan for 
35 a selected product {^oup. The objective is to ensure that the resultir^ PSl plan 190 meets customer requirements and 
satisfies supply capabilrty constraints and the inventory objective of the company. The current PSl plan 1 90 is displayed 
together with a temporary PSl plan 190. The temporary PSl plan 190 can be imported from various data sources 
(including data series from Sceriarios 78). The user can then analyze and nrxxiify the temporary PSl plan 1 90 with easy 
reference to the cun-ent PSl plan 190. The user can replace the current PSl plan 190 by the temporary one once ttie 
40 latter has been irrproved to satisfaction. 

The PSl planning process requires ttie support off three modules: the Sales Forecasting arxJ Planning (SFP) Mod- 
ule 132, the Aggregate Production Planning (APP) Module 162 and the Finished Goods Inventory Management (FGIM) 
Module 164. 

45 Forecast Recondliation 

The Demand Management Frame 130 supplies the Forecast Data 1 46 (bottom-up and top-down forecasts) and an 
indication off the methods used to generate them. The user can use the same methods to generate new forecasts and/or 
compare the forecasts generated by different methods. The user analyzes and reconciles these forecasts to generate 
50 an appropriate set of sales requirements. The PSl Reconciliation 1 70, with the support of the SFP Module 1 32, revises 
forecasts and reconciles top-down and bottonHjp forecasts. 

Revise forecasts 

55 The forecast revision process acquires, displays, analyzes and edits the bottom-ip or top<iGwn forecast The user 
first acquires forecasts generated using different methods from the Demand Managenr>ent Frame 130. After analyzing 
these forecasts and comparing the results, the user then sheets the most appropriate one to be used. The follcwing 
features are identified for this process: Acquire and display forecasts; Check forecast errors; Compute and display 
related statistics off sales; and Select forecasts. Individual desaiptions off these four features are as folkiws. 
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Acquire and display forecasts. 

Ths feature consists of the follownng four steps: 

Choose product group: The user specifies the product grotp of interest 
5 Choose aggregation level: The user spedftes the aggregation level (e.g. month, year) for data display. 

Import forecasts: The DSS 10 acquires the bottom-ip and top-down forecasts generated in Demand Management 
Frame 1 30 for the selected product group from the DSS Database 12. 

Display forecasts: The DSS 10 aggregates/dsaggregates as appropriate the forecasts to display at the chos^ 
aggregation level. 

10 

Check forecast en-ors 

The forecast error checking feature supported tiy the SFP Module 132 computes and displays various n-period- 
ahead htetorical errors of the bottom-up and top-dcwn forecast 

75 

Compute and display related statistics of sales 

The sales statistk;s computation feature supported by the SFP Module 132 computes: mean and variance over a 
selected time interval, moving average, trerxl. and/br seasonality factors of any chosen sales line and display result in 
20 several forms (graphk;al, tabular or both). 

Select forecasts 

The forecast selectfon feature interacts wHh the Demand Management Frame 130 to check bottom-up forecasts 
25 from various sources and the result of various topdown forecast methods (e.g. moving average, regression, comtxna- 
tions. etc.) The user then chooses the most appropriate set of bottonrhup and top-down forecasts based on their accu- 
racy, statistics arxf consistence with each other. 

Recondle top-dcwn and bottom-up forecasts 

30 

The process of top-down and bottom-up reoorrciliatfon checks the discrepancy between the two forecasts and If 
necessary, resolves the conflicts between the two forecasts to generate a more desirable sales forecast The following 
features are provkted to support this process: Compute the difference between top-down and bottom-up forecasts; 
Generate weighted average of top-dcwn and bottom-up forecasts; arid Manually ovenwrite temporary sales (S*) line 
35 (see the screens discussed later herein). IndrvkJual descriptfons of these three features are as follows^ 

Compute the difference t>etween top-down and bottom-up forecasts. 

The difference between top-dcwn and bottorrHip forecasts is corrputed and displayed to show the discrepancy 
between the two forecasts. 

Generate weighted average of top-down and bottom-up forecasts. 
40 The conflicts between the top-down and bottonrHjp forecasts can be resolved by 
to generate a new temporary sales forecast in the S* line. 

Manually ovenwrite temporary sales (S*) line 

The user manually overwrites the forecast on the S* line to adjust the sales forecast to reflect various consxJerations 
of influential factors. Rx example, adjust sales forecasts to account for unrecorded or anticipated upcoming mart^ 
45 changes. 

Inventory Planning 

The process of Inventory Planning supported by the FGIM Module 164 and the Demand Management Frame 130 
50 determines the f insh goods inventory requirements. In inventory planning, the user first selects a product group. To help 
the i^er to select an appropriate inventory policy, the DSS 10 computes and displays various sales measures which 
characterize the sales pattern of the chosen product groupi For example, a MIn-Max policy might be appropriate for a 
product group facing steady demand. The DSS 10 then, based on the inventory polk:y selected by the user and the 
managerial sales and sennce targets, d^ermines the policy parameters and inventory level requirements. The user can 
55 then modify the polk^ parameters and inventory level requirements to satisfy various managerieil requirements and pro- 
ductfon resources limitations. The following two features are klentif led for this functional requirement: Formulate fin- 
ished goods Inventory polk^ies; and Determine finished goods inventory requirements. 
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Formulate firashed goocte inventory policies 

The formulation of finished goods inventory policies involves the selection of inventory po&des for chosen product 
groups and specifying the corresponding polk;y paranieters. It is bro)^ dcwn in^ 
tory policies for product groL9>s; Choose policy parameters: and Compute estimated inventory statistics. 

Individuat descrptions of these three features are as follows. 

Choose inventory policies for product groups 

In this feature, the user select inventory policies for product groups based on the pattens of sales the product 
groups are facing. It involves the follGwing three steps: Choose product group: The user spedftes the product groijp(8) 
of interest; Acquire the following sales measures from the Demand Management Frame 1 30: Usage rate - fast, medium 
or slow moving. Lurrpiness - sparseness of significant demands, and Volatility - coefficient of variation; and Select 
inventory policy: The user chooses among the following an inventory policy for the chosen prodjct group(s) based on 
the sales information acquired. 

For single product group with non-lumpy demarxis: User-specified t)as6-stock policy. Periodic review cost optimi- 
zation policy, and Period review model with servk;e level constraints. 

For related multple product groups (e.g. groups sharing the same proc&jction resources.) with non-lumpy 
demands: Leveled Policy, Synchronized Policy, and Optimal Policy. 

For single product groip with lumpy demand: Maximum n-Period Coverage Policy. 

Choose policy parameters 

The FGIM Module 164 based on the service level constraints and managerial ot>jective (e.g. minimize inventory 
canyingcostwithastockoutprobalnlityof atnrK)6t5%)detennmnesthepdk^ inventory 
policy chosen by the user. The user can then observe the results of the estimated inventory statistics and adjust the 
policy parameters as appropriata 

Corrpute estimated inventory statistics 

The estimated inventory statistics calculation feature supported by the FGIM Module 164 conrputes and cfisplays 
the following inventory related measurements: average inventory level (as weeks of sales); expected stock-out proba- 
bility; sennce level (fill rate); inventory carrying cost; arxi total cost (including production, inventory holding, stock out 
penalty and transportatk>n costs) for the chosen inventory policy and policy paramet 

Determine ftrushed goods inventory requirements 

The FGIM Module 164 based on the inventory policy arxf poTicy parameters determines the finished goods inven- 
tory requirements for the product groups. The user can then modifies the inventory level requirements as appropriate. 
The following features are identified for determining the finished goods inventory requirements: Compute and display 
inventory level at chosen aggregation level; Manually override inventory levels; and Compute and display inventory level 
at chosen aggregatk>n level. 

The PSI Planning Frame 160 supported by the FGIM Module 164 computes ttte inventory levels based on the cho- 
sen inventory pdkaes and parameters. The result will be displayed in the terrporary inventory {V) line. If the conrputatkni 
is done at a lower aggregatk>n level than the chosen one for display, the coresponding appropriate aggregation will be 
done before display. 

Manually override inventory levels 

The user can manually ovenvrite inventory levels to reflect various managerial cortcems. For example, the unavail- 
ability of production resources at certain periods requires the decrease in con-esponding inventory levels a the sug- 
gested inventory level exceeds the given management target 

Supply Requirement Planning 

The supply requirement planning feature supported by the APP Module 160 help determines the production 
requirements that are consistent with the sales plan and the inventory requirements. It also checks the feasibility of the 
production requirements with respect to production capacity and key component availakxirty. In case of infeasft)ility, the 
feature will provide information atXHJt the cause of corresponding infeasit>ility to the user. The user can then modifies 
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sales requiremenrts. increases available resources (production capacity or key component availat)ilrty) and/or prioritizes 
the sales rec^irements and restricts attention to satisfy a reduced set of high priority sales requirements only in order 
to achieve feasitxiity. 

Determine production requirements to sustain sales 

The process of determining production requirements to sustain sales consists of the following two features: Gener- 
ate production requirements; and Manually overwrite the production requirements. Individual descriptions of these two 
features are as follows. 

Generate production requirements 

The production requiremerrts generation feature supported ty the APP Module 160 determines the production 
requirements t>ased on sales and inventory requirements. There inventory requirements may take two different forms: 
Inventory labels, or Safety stocks. 

In case of inventory level requirements, the production requirements are generated using the inventory k>alance for- 
mula dscussed herein. 

In case of safety stock inventory requirernents, the user can choose one of the foikjwirig objectives to determine 
production requirements: Minimize the maximum production capacity utilization; Minimize the maximum inventory level; 
Minimize the total inventory level; and Minimize the total inventory cost (inventory hokJrng and bacMog penalty costs 
required). 

The production requirements generated are displayed in the temporary production (P^ lina If result of sanity check 
is at a kNi&r aggregation level than the one chosen for display, aggregatk)n will be done before display. 

Manually ovenwrite the production requirements 

The production requirements are modified to reflect various considerationa Fof example, insufficient production 
resources during certain periods. 

Check aggregate production capacity & key corrponerrt availability 

In the process of checking the feasa^ility of sales, inventory and production requirements against the availability of 
production capacity and key components, the fblk>wing features are identified: Define key corrponents; Check sanity of 
a given set of sales requirements (in S' line) and safety stock constraints; Check feasibility of production requirements 
(in P* line); and Update and dteplay productkxi capacity load and key component availability. Individual desCTiptions of 
these fou features are as follows. 

Define key corrponents 

Each user defines a list of key conrponents, which is recorded arxJ can be modified whenever necessary. The list 
of all conrponents whk;h are sorted according to their availabilityAisage ratio is displayed to help the user to define or 
modify the list of key conponerrts. 

Check sanity of a given set of sales requirements (in S' line) and safety stock (in t* line) constraints 

The process of sanity check utilizes the capacity checking model in the APP Module 160 to help determine the pro- 
duction requirements for the given set of the sales requirements and safety stock constraints. Furthermore, the user can 
scope the capacity checking model appropriately through modif icatk>n of: Locatk>n(s), Products or product groups. 
Time horizon. Production lines, and oomponentSw 

If the results of the capacity model are infeasfcle, crittoal under-capacttated production resources and key conrpo- 
nents are suggested to the user for further nrxxiif icatior^ 

Check feasi>ility of production requirements (in P' line) 

This process checks sanity of a given set of production requirements against the production capacity and key com- 
ponent availatMlity. This is also supported t>y the capacity checking nrxxJel in the APP Module 160. Similar to the previ- 
ous sanity check described above, the user chooses the appropriate scope of the capacity checking nrxxlel and if it 
turns out to be infeasft)le, critical under-capacitated production resources arxl key conrponents are suggested to the 
user for further nrxxirfk^ation. 
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Ujpdate and cfisplay production capacity load and key oonponent availability 

After a few iteratiorts of the sanity checks and capacity requirement acijustment. the user can reach a feasitsle set 
of production requirements. The remaining available production capacity and components are updated and can be 
5 d^played if requested. The user can then accept or reject new production requirements based on the availak>ility of pro- 
duction capacity and key components. 

Proc^ctiorvSales-lnventory Plan Coordination 

10 The coordination of tfie productiorvsales-lnventory plan ensures consistency among the production, sales and 
inventory plans arKi helps determine a feasit)le and appropriate RSI plan >90. 

Check and ensure consisterKy in PSI plan 

15 The user can utilize this feature in either: the independent mode or the consistent mode. 

In the fonmer mode, the user can edit the production, sales and inventory requirements separately disregarding 
any consistency requirement. In the latter mode^ the DSS 10 always ensures the consisterK^y of the production, sales 
and inventory requirements. In the consistent mode, the following features are identified: Modify the plan according to 
the user defined sequence; Maintain the oonstetency in other lines due to the charrge of one line; Update the production 

20 (P), sales (S) and inventory (0 lines (see display figures discussed herein) by their corresponding temporary fines; 
Maintain consistency at different aggregation level (for either the consistent or independent modes only). Individual 
desaiptior^ off these features are as fblkyws. 

Modify the plan according to the user defined sequence 

25 

When the user first switches to the consistent mode, two of the temporary production, sales and inventory lines 
have to be selected to generate the tfiird line using the inventory balance formula discussed herein. 

Maintain the consistency in other lines due to the change of one line 

30 

Whenever a temporary production, sales or inventory line is cvenwritten, it will be nxxJified together with one of the 
remaining two lines (prelected and can t>e re-selected anytime by the user) to maintain consistency 

Update the production (P), sales (S) and inventory (I) lines by their corresponding temporary lines 

35 

The user can replace the set off P, S and I display lines (see dsplay discussion herein) by a set of consistent P', S' 
and r lines. The P. S and I lines can always t>e saved as a scenarkx Only user with the appropriate system privilege can 
save the P, Sand I fines to the DSS Database 12 permanently 

40 Maintain consistency at differerrt aggregatfon \BieA 

The DSS 10 can display data at any resolutfon higher than the prinriary data resolution level. Whenever display at 
a higher resolution is nrKxjified, dsaggregatfon will t>e done to maintain consistency. The DSS 10 computes a set of 
default disaggregation logic based on eodsting fowest resolution data. The user can overwrite the disaggregation logic 
45 whenever appropriata 

Evaluate PSI plan options 

The PSI plan options evaluation feature computes and displays the performance metrics for various versions of the 
so PSI plan 1 90 for the user to compare and choose a desiratsle one. The following two features are ktontified to support 
tfiis feature: Compute relevant performance metrics; and Compare cfifferent plarrs. Individual descriptions of these two 
features are as follows. 

Compute relevant performance metncs 

55 

The following performance metrk:s are computed using the routines specified in the SFP 132, FGIM 164 and APP 
Module 160 to assist the user to select a niore desirat)le version of the PSI plan 190: Total and breakdown of costs, 
Average inventory level. Average expected stock-outs, E4>ected Throughput Tima, and Expected Service level. 
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Conpare different plans 

Different PSI plans 1 90 ever the same or cfifferent time periods together with their corresponcfing performance met- 
rics are displayed side by side for comparison purposes. 

5 

Repair EnviFonment 

In the Repair Environment the term "Requirements-Supply Reconciliation' is used in place of ProductiorhSales- 
Inventory planrting. This reflects the fact that there is no production nor sales in a repair environment txjt "repair require- 
10 ments" and 'repair supply" in the form of repair workstation capacity and component availability "Requirements-Supply 
Reconciliation" Planning is a reconciliation process that develops an integrated and feasft)le plan. 

The Requirements-Supply Reconciliation comprises of two main processes: Estimation of the aggregate repair 
rec^irements t>ased on the inventory position of serviceable parts at the repair location and the target level for ttiis 
inventory; and Feasibility assessment for ttie aggregate repair requirements under resource capacity (skills and work- 
15 stations) and component availability constraints. To support these processes tiie following functional requirements have 
been defined. 

Evaluate and propose Consolidated Serviceable Inventory (CSI) Levete based on past usage and future us^e 
requirements. 

The following operations are performed: R^ine variat>ilrty and lumpiness estimates of usage; Refine repair lead 
20 time estimates; and Propose target CSI levels 

Determine Aggregate Repair Requirements 

Ihfs includes using target CSI levels, and current inventory positions to determine ag^egate repair requirements. 

25 

Generate Aggregate Repair Plan 

This includes the following: Verify repair resource capacities to satisfy aggregate repair requirements based on; 
repair personnel skill sets; workstations features; Verify key component availability to satisfy aggregate repair require- 
30 merits; and Generate ^regate repair plan under capacity and component constraints. 

Supply Management 

The Supply Management Frame 200 supports the Supply Management decision process. 

35 

Module and Data Space Association 

Figure 18 shows the participating modules and the associated data spaces for this Frame 200. 
40 ProcessFfow 

The process f kiw diagram for the supply planning frame 200 is shown in figure 1 9. The Supply Management Frame 
200 supports the fblfowing functional requirements ktentif ied for ttie Supply Management decision process: 

45 Aggregate Productfon Planning 

The APP Module 160 works closely witti the FGIM Module 164 and uses Inventory Data 182 and the Productfon 
Capacity Data 180 to evaluate production and inventory trade-offs. The APP Module 160 also uses the Production 
Requirements Data 174 from the PSI Planning Frame 160 to generate aggregate production plans. These are written 
so to ttte Aggregate Production Plan Data 202. 

Dynamic Replanning 

The aggregate production plan is often modified by ttie APP Module 160 to reflect eitfier changing production 
55 requirements provided by the PSI Planning Frame 160 through the Production Requirements Data 174 or changing 
component availability from the Material Planning activity 210 through Material Delivery Schedule 212. 
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Capacity Planning 

The APP Module 160 utilizes long-term Production Capacity Data 180 from the Product Planning activity 214. the 
production paran^eters such as process tmes from Production Matrix 21 6. and the planning bid-of-material for the prod- 
uct from Planra'ng BOM 218 to determine the production capacity requir^nents. In so doing, the APP Module 160 
evaluate a number of production capacity options such as varioi^ production line structures and allocation of 
resource& The capacity plan is written to Production Capacity Data 180. 

Component Procurenient Policy Development 

The Component Procurement Policy Development (CPPD) Module 230 reviews the long-term component require- 
ments in Corrponent Requirement Data 232 and other relevant component supply information to formulate conrponent 
procurement policies. The conrponent procurement policy parameters are then written to Component Supply Contract 
234. 

Data Row 

The data flow diagrams for the Supply Management Frame 200 are shown in figure 20 arxi figure 21. The Supply 
Management Frame 200 generates the core report previously discussed, namely, the Master Production Plan 240 arvi 
the Production C^>acity Plan 242. 

Vendor Managed Replenishment Frame 

The Vendor Managed Replenishment (VMR) Frame 250 supports the VMR decteion process. 
Module and Data Space Association 

The Data Space associations for Frame 250 are illustrated in figure 22. 
Process Row 

The process flow diagram for the VMR Frame 250 is shown in figure 23. The VMR France 250 supports the func- 
tional requirements identified for the VMR decision process: 

VMR Strategic Planning. 

The VMR Strategic Planning activity 252 in concert with the MDA Module 134 and the FGIM Module 164 considers 
the financial and txjsiness requirements supplied t>y the custonrrers, dstrbution infrastructurOp POS history arxi the 
transportation factors in the Supply Chain Network data table 260 to evaluate various service contract options. The 
VMR contract parameters are then written to VMR Contract 262. 

Replenishment Planning 

The Replenishment Planning activity 270 working with the MDA 134 and the SFP Module 132 reviews the sell- 
through information and provides input to the FGIM Module 164 to generate the corresporxling replenishment require- 
ments. These requirements are refined according to the VMR Contract 262. Based on these inventory requirements, 
the VMR Contract 262 and the order fulfillment activity, tiie replen^ment schedule is generated and written to VMR 
Data 272. 

Data Row 

The data flow diagram for the VMR Frame 250 is shown in figure 24. The VMR Rame 250 generates the Replen- 
ishment Schedule report 280 listed earlier. 

VMR. also referred to as cfirect replenishment is a growing agile logistics partnership agreement where the vendor 
takes on the responsibility of managing the inventory at the customer sites for the products it supplies, i.a, monitoring, 
planning, and directly replenishing the inventory in the customer's distrit>ution network. In other words, under a VMR 
arrar)gement it is the vendor who determines when stocks are to t)e replenished and in what quantities, rather than 
responding passively to orders placed by the retailer. This arrangement is usually typified by a contract which specifies 
the financial terms, inventory constraints, and performance targets such as servk^e measures. VMR is sAmosX invariably 
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based on the availability of direct access to point-of-sale data and ttie customer's inventory positjons. Such an arrange- 
ment can be mutually advantageous to the customer and the supplier. 

On the other hand. VMR requires the integration of inventory and transportation planning processes of the supplier 
and the customer. Although much has been written in the general literature about VMR as a concept (eg.. W^Marfs 
5 relationships with its suppliers) there are few known quantitative models, if any, to sipport VMR. Existing VMR systems 
are transaction oriented and provide littie or no decision support capabilities. 

The VMR Rame 250 consists of a set of decision sipport tools that can be used in tiie development of VMR pro- 
grams. The features offered by the VMR Frame 250 support tiie decision making processes in the VMR programs at 
both strategic and operational levete. More specifically, at the strategic level, the user can invoke the features provided 
10 by the Frame 250 to study of ttte feas&ility of VMR programs; evaluate the terms of VMR contracts; and perkxitcaDy 
review the cverall performance of the VMR program. 

At the operational level, the user can invoke the Frame features to develop sell-ttirough forecasts; obtain suggested 
replenishment quantities; revise replenishment quantities; and monitor sales and other VMR related statistics. 

In this section, we will provkle the functional specification for tiie VMR Frame 250. The entire Rame 250 can be 
IS partitioned into three main parts: bask; arvJ VMR specif k; data maintenance, strategic planning and replenishment plan- 
ning. It supports tiie foHowing two functional requirements: VMR Strategk; Planning: Evaluate finandat and logistical 
tradeoffs in a VMR contract, and Corrparative analysis of varous service contract options; and ReplenishnYent Plan- 
ning: Review sell-through and determine inventory requirements at retailer's location, and Famulate the replenishment 
plan. 

20 The main dedskm modules to support the VMR Frame 250 include MDA 134. SFP 132, VMR and APP 160. We 
will discuss tfie functional specifications tfiat are applicable to the manufacturing environment 

Data Maintenance 

2s To support general functionality of the VMR Frame 250. the system should maintain two types of data: the Bask; 
Structural Data and ttie Replenishment Data. In the follcwing two sut>-sections we discuss tiie details of tiiese two sets 
of data. 

Bask; Structural Data 

30 

These include the essential data elements required to desCTft>e the t>ask; characteristics of tiie products, distribu- 
tion network, etc. This set of data are relatively stat>le and require only infrequent updates (e.g.. at the time when the 
VMR program is being initialized, or when new models are being added to the program). These include: 

35 Distribution Network: Define tfie customer as well as tfie verKk)r*s product distribution networks that are relevant to 
the VMR progrant It kJentifies whk;h product is k>eing distrftxjted from whk;h vendor ^^ehouse and whk;h cus- 
tomer Distribution Center (or store) are assigned to each warehouse. 

Distrbution Center (DC) Profile: Define the main attrftxites of a customer DC or a vendor warehouse including its 
kx;ation (city and state) information. 
40 Lead-times: Define the lead-time for product distribution between a given pair of locatioris and the corresponding 
transportation modes. 

Transportation Costs: Deline the transportation costs for product distribution for given transportation modes. 
Product Profile: Define tiie main attributes of the products participating in the VMR program including their IDs and 
physical characteristics. It also specifies whettier a product is currently in tiie VMR prograra 
45 Product Replacement Relationship: Define the relationship between a current product arxl its predecessor (k>eing 
replaced). This provides the basic information to establish a continuous demand stream for a pair of closely related 
products. 

Replenishment Data 

50 

Replenishment data are more dynamic, and record the details akxxit the replenishment activities as well as the 
characteristics of the VMR program itself. These include: 

Produd and DC VVktch List A set of products and DCs that are defined by the user to be monitored by the system 
55 so that any special movements or activities can be detected and reported. 

Seasonality Factors: The set of factors cakxjlated l>y the system or provkied t)y the user to characterize the fc>ask; 
seasonal fluctuation patterns In the sales activities. 

Replenishment Orders (Receipts, In-transit. Incomplete, etc.): The detailed order status information tfiat is 
recorded to capture tiie replenishment activities included in ttie program. 
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Maximum and Average Inventory Levels: The targeted maximum arxj avmge inventory levels specified in the VMR 
contract They can be used to monitor the current performance of the VMR program. 
Service Levels: The targeted customer service levels specified in the VMR contract 

Delivery Frec^ency: The delivery frequency is defined by the user or the system and it specifies the frequency at 
5 which the products are replenished for a particular customer DC. 

Promotion Calendar: The calendar captures the relevant promotion activities. This information is then used to 
ensure that a sufficient additional amount is included in the regular replenishment quantity. 

Strategic Planning 

10 

Strategic planning features mainly si^sport VMR decisions during the initial program setup; important during VMR 
contract negotiation stages. They are also useful to provide critical operating parameters, ag., replenishment frequen- 
cieSw Rnally, they are also needed to corxkict lorig-term performance reviews. Therefore, the functions provided at the 
strategic level are addressing the issues which are of long-term importance, even though these dedsions are not made 
15 so frequently 

VMR Contract Setup 

During the initial stage of potential engagement in a VMR program, the corxiitions in the VMR contract are pro- 
20 posed, studed and negotiated. Under such circumstances, the user needs to evaluate the costs and benefits of many 
different program options^ When the terms are conflicting, tradeoffs have to be mada In addrtioa one also has to 
choose a set of operating parameters and procedures which optintize total cost measures wNle satisfying given con- 
straints. The features provided belcw are to sufDport these decision making problems. 

For a product/product group, a customer DC, and a delivery frequency defined by the user, the system will provide 
25 the computed relationship between expected service level and maximum (average) inventory level. Such a relationship 
win also be useful for the user to evaluate what-if Scenarios and can be used in other features in this Frame (e.g., ttie 
Replenishment Planning below). 

Compute and dsplay expected service level for the maximLvn inventory requirement defined by the user. 
Estimate and display the proper inventory level for a given service level defined by the user. 
30 When evaluating the optimal VMR operating paranf)eters or conditions in the contract, the system can help the user 
to either check the corrpatibility of a set of constraints including service level, inventory level and delivery frequency, or 
select an optimal set of these parameters after the evaluation of all feasible combinations. 

To use this feature, the user first needs to choose the product/product group and the DC of interest. 
For a given replenishment scenario (a given set of delivery frequency, target irrventory level arxi customer service 
35 level), the system will estimate the total cost including customer DC inventory carrying cost, transportation cost and 
manufacturing plant inventory carrying cost 

Different replenishment Scenarios can be generated t>ased on different values of delivery frequency, target average 
inventory level arxi target customer service level. In order to compare tiiese dfferent options without using total pro- 
jected costs like the one suggested in the featif e above; the system will compute key statistics such as expected inven- 
40 tory levels at customer DCs and manutacturing plants. By comparing these statistics, a better replenishment scenarb 
can be identified. 

Contract Parameter Monitoring and VMR Progam Review 

46 After a VMR program has l>een setup arvl tfie execution started, it requires constant monitoring of the key polk;y 
parameters and performance measures. If there are sut>stantial changes, it is critical to report them t>ack to ttie users. 
This is because ttie optimal operating paranrteters in the VMR program set at the strategic level are obtained under cer- 
tain assunrptions about these key indk»tor& In addition, periodteally, the management will be interested in the actual 
effectiveness of the VMR program. To support such program reviews, the system will record and generate management 

50 reports regarding the actual performance of the VMR program compared to tiie inventory and customer servk» level 
targets set in the VMR contract. 

Periodically (which can be defined by the user), ttie system will compute the mean and standard deviation of ttie 
sell-tinrough for a given product of a given customer DC. The resulting nurTt>ers can ttien t>e compared to the historical 
nomn defined by the user, the quantitative modeling assumptions, or recorded by the system. If the mean and standard 

55 deviation are outside of ttie defined range, then ttie user has to be informed ttirough a product sales exception report 
or other similar reports. The user will t>e asked to define the following: Requency of such evaluation; Historical norm of 
the mean and standard deviation; and The ranges of the mean and standard deviation. 

One of ttie key objectives of any VMR program is to reduce ttie total inventory levels at different parts of ttie supply 
chain. The system will compute and record average inventory levels and compare it to maximum and average inventory 
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targets. The results can then be reported to the user as requested. 

When the inventory level of a given product/jproduct group at a customer DC Is much higher than needed, part of 
the inventory should t>e considered as excess. The system will report the list of products whose inventories are in 
excess. These products then will be off the replenishment product list until the inventory levels return to a normal range. 
5 During these periods, the production and many other logistics operations planning will have to be notified about the 
reduction in planned quantities. 

Replenishment Planning 

10 Thte is to support more operational decision problems on a regular basis after the VM R program has started its exe- 
cution. During this stage, the main concerns of the i^er will be shifted to those of a more operational flavor such as the 
generation and revision of the replenishment order to satisfy target customer service levels and maximum inventory 
constraints. In addition, in order to ensure the validity of the decision support models and prepare the decision makers 
for changes in the market place, the system will monitor certain operational incficators relating to the VMR progrant The 

IS indicators and purpose of this monitoring are dstinctively different from the monitoring and review function offered at 
the strategic level. 

Sell-through and Demand Orientation f=brecasts 

20 Before we can start to use the system to generate replenishment orders, a s^ of sell-through forecasts have to t>e 
developed. We win use the models developed in SFP 132 using POS as the primary data source. On the other hand, 
the production planner at the manufacturing vendor needs to know longer term forecasts to plan for future capacitiesw 
To that end, the system allows the user to devefop and examine not only the replenishment quantity of the next replen- 
ishment cyde but also to extend several periods ahead so that these fonger term forecasts can also t>e estimated and 
25 used for other (e.g., manufacturing) planning purposes. 

Based on the sell-through data provkied t>y the cu^omer for a given product/jproductgxM^ at a customer DC, the 
system will generate sell-through forecasts including mean and standard deviation for any given product at a customer 
DC. The actual forecast algorithm will invoke an appropriate one specified in the SFP Module 132 which shoukJ con- 
sider trend, arxi seasonality among other basic aspects of the data stream. In case of a product having too little sell- 
so through history, the system will use the proc^ replacement relationship defined to estat>lish more continuous sell- 
through history. In additfon. the system will also permit the user to select an appropriate length of historical data to 
account for at>normal sales activities for flie product. 

The system will also generate fonger term replenishment requirements lor the demand orientation for a given prod- 
uct so that the user can plan for the fonger term demands for ttie product. To generate mecfium to long term forecasts, 
55 the system will first forecast the sell-through for the specified time periods by invoking appropriate forecasting algo- 
rithms in the SFP Module 132. Thea a set of replenishment quantities will be generated using the replenishment algo- 
rittim in the VMR mocbila These replenishment quantities will then k>ecome the demand forecasts for the product 

Replenishmerrt Order Generation 

40 

The generation of replenishment orders is the main functionality of the replenishment planning of the VMR Frame 
250. The main objective of the functionality is to provide the user with an initial set of replenishment quantities for a set 
of products witti the consideration of the sell-tiirough forecasts as well as VMR specific operating parameters. The 
quantities will then k>e approved by the user and converted into actual purchase orders. 

45 Based on the forecasts of ttie future sell-through, user defined VMR operating parameters (ag., customer servfoe 
level, maximum inventory level and delivery frequency), and other related indicators (ag., last reported customer DC 
inventory level), the system v^ll generate a suggested replenishment quantity for a future replenishment data 

If the product nrxxtel year changes are regular, then it is necessary to treat the replenishment quantity needed for 
product (or VMR program) initialization and termination differently from the regular replenishments. Therefore, the 

50 akxyve feature has to t>e modified to t>6 applk^able to these settings: 

Set Initial Replenishment Quantities: The main differerx^e t>etween the initial replenishment quantity setup arxJ the 
regular one is that it may require adcfitional quantities to fill customer DCs or stores. In adcfition, t>ecause there s 
no sell-through history availatile for these new products, the history for the replaced products will have to be i^ed 
55 in the computation. It is also necessary to set a time frame for ttie oorrputation algoritttm to use a new product's 
data when it accumulates enough data of its own. 

Balartce^ at the End of a Season: At ttie end of a selling season, a product needs to be phased out In such a 
situation, the system will not generate any furttier replenishment quantities for the product unless the user deckie 
to ovenvrite the suggested (zero) quantities for a special reason. 
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For a given customer DC. when the products are being considered for replenshment, the system will help the user 
set joint replenishment orders so that the total cost for the replenishment k>atch can be minimized. The basic logic is to 
add or delete products included in a replenishment batch to optimally use the transportation means while maintaining 
satisfactory customer sennce level and inventory level. 
5 The system wfll also automate the replenishment quantity generation for a set of products selected by the user. 
Ths feature is useful especially when the number of products in the VM R program is relatively large and the user pre- 
fers to mrk only on exceptional issues rather than examining the details of each product's replenishment activities. 

Replenishment Order Revision 

10 

After the initial replenishmerrt quantity has t>een generated for each product tfte user may be interested in exam- 
ining the entire or only a selected set of products to make sure that the soft information can be reflected in the actual 
replenishment orders. In adcfition. a number of constraints such as product availability and production capacity will also 
have to be taken into consideration. The objective of the features listed below is to help the user revtee the replenish- 
es ment orders with relevant analysis and search support tools. 

The user can define a set of exceptional report generation criteria so that the system can search for and display the 
products falling into the ranga The sarrple user-defined criteria will include 

Mean and standard deviation exceeding certain Omits of the historical norm 

The customer DC inventory exceeding the maximum inventory level after the suggested replenishment quantity 
20 arrives 

For a given replenishment quantity (either recommended by the system or input by the user), the system win esti- 
mate arKi display the probat»lity of stock-outs. To compute the probatwiity value, a search algorithm is needed in addi- 
tion to the relationship t>etween inventory quantity, customer service level and delivery frequerv;y. The user can use the 
feature to evaluate whether the replenishment quantity suggested is satisfactory or not 
26 Most of the replenishment quantities discussed here are appropriate for non-pnunotional sales. When a promotion 
for a product is planned, the user should be informed so that ihe final replenishment quantities can incorporate addi- 
tional quantities due to the promotion. The objective of this feature is to identify pronxytion events during a given replen- 
ishment review period and help the user incorporate additional quantity for the events. 

Before the replenishment orders can be finalized, the DSS 10 will make sure tfiat the vendor can supply the 
30 required quantities in the specified time frama If the replenishment order shipment date is dose to the review date, then 
the product (finished goods) availability will be checked; and if the shipment date is further into the future, then the pro- 
duction capacity will be examined. 

In order to properly make tradeoffs between different replenishment Scenarios, the system will estimate the total 
cost (including the inventory and transportation among others) for a given set of replenishment quantities. The cost will 
35 be corT^Hited automatically as the user is making nuxlif ications in the replenishment ordersw 

To reduce the transportation cost, a rough-cut truckload planning tool will be provkled to the user so that the room 
left on a truck can be fflled by other most-needed products for the same customer DC. The underlying fogk; Is to build 
a truddoad of shipment whenever it is possfola 

40 Sales Activity Monitoring and ReplenishmerTt Review 

The movement of product sales reflected in the sell-through data will have different impacts on the future replen- 
ishment activities as well as the m^hods used to generate recommended replenishment quantities. Therefore, the sys- 
tem will provide the monitoring and tracking capabilities for the user to better manage the sales changes. In addition, 
45 the operating parameters specified in the contract will also be monitored so that the user can be reminded whenever 
the replenishment quantities are likely to exceed the limits in the contract 

The system will compute and maintain the historical norms of mean and standard deviatfon of sell-through so tiiat 
they can be compared to the similar quantities in the most recent periods. It is an indicator of sut)stantial sales changes 
*rf the recent sales deviate from the user specified ranges of the historical norms. 
so The system will monitor whether the suggested replenishment quantity is going to exceed the maximum inventory 
le^el allowed in the VMR corrtract The user will then be notified to take further action. 

On a regular basis, the system will record a set of tracking signals and corrpute forecast errors so that when sufc>- 
stantial changes occur, it should be reported t>ack to the user to take further action. 

55 Distritxjtion Network Design 

The Distribution Network Design Frame 290 sif}ports the Distribution Network Design. 
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Mcxiule and Data Space Association 

Figure 25 shows the participating nnodules and the associated data spaces for this frama 
5 Process Flow 

The process flow diag'am for the Distribution Network Design Frame 290 is shewn In figure 26. The Distrikxjtion 
Network Design Frame 290 supports the functional requirements identified for the Dlstr03ution Network Design dectskm 
process: 

10 

1. Distrikxjtion Location Analysis 

The Rnished Ckxxis Network Design (FGDND) Module 292 works with the MDA Module 134 and the SFP 
Module 132 to develop a forecast of aggregate long-term demand which is then used to evaluate potential Distri- 
txition Center (DC) locations. The chosen DC kx:ations are then written to Inventory Node 294. 
75 2. Distritxjtion Network Optimization 

The FGDND Module 292 works in concert with the FGIM Module 164 to optimize the overall network configu- 
ration. The result of this optimization is the assignment of demand nodes to DCs and the assignment of production 
nodes to DCs. This information is tfien written to Sif)ply Chain Network 296. 

20 DataFkiw 

The data flow diagram for the Distrikxjtion Network Design Frame 290 is shown in figure 27. The Distrikxjtion Net- 
work Design Frame 290 generates two of the core reports listed earlier, namely, the Customer-DC Assignment 300 and 
the Supply-DC Assignment 302. 

2S 

Model Engine and the Modules 

In this sut>section, the overall design of the Model Engine 20 is introduced. The objective, scope, and features of 
the sa^en constituent nrxxiules of the Model Engine 20 are discussed. 
30 The Model Engine 20 consists of a Ibrary of specialized quantitative models and analysis routines. To address the 
needs of a set of users, a Decision Support Frame calls and assembles these models and analysis routines with the 
appropriate data. 

The number of models and analysis routines within the Model Engine 20 could be quite large by virtue of the mod- 
ular design and inherent conr^exity of the DSS 1 0. To k)etter manage the Model Engine 20, there is a need for logically 

35 grouping the nrvxiels and analysis routines. Furthermore, these models and analysis routines support major decision- 
making areas in a supply chain. Therefore, the models and analysis routirm are grouped into seven modules corre- 
sponding to the principal dedsforMnaking areas in the supply chain as shown in figu-e 28: Market Data Analysis (MDy^ 
134; Sales Forecasting & Planning (SFP) 132; Vendor Managed Replenishment (VMR) 252; Finished Goods Inventory 
Management (FGIM) 164; Ag^egate Production Planning (APP) 162; Component F>rocurement & Policy Development 

40 (CPPD) 230; Finished Goods Distrbution Network Design (FGDND) 292; A frame by virtue of hs definition may reqidre 
the participation of some subset of modules O e., the models and analysis routines of these modules will be involved). 
In the case of the PSI Planning Rame 160. the MDA 134, SFP 132, FGIM 164, and APP 160 Modules will be involved 
in constituting the decision logic 76. 

In many cases, the same models arxi analysis routines may be employed by dtetinct frames in different contexts, 

46 where the relationships k>etween tfie nrxxlels and the associated data linkages vary accordingly. This requires that the 
Supply Chain Frame Manager 24 interact directiy with the nrKxiels and analysis routines in the Model Engine 20. The 
models and analysis routines will therefore have standard data and fogic input/butput (1^) formats. The standard I/O 
formats will also facilitate the maintenance of the individual models and analysis routines, e.g., updating arxi replace- 
ment. 

50 In addition to tiie seven modules defined atxive. there is also a 90up of general purpose numerical routines ttiat 
are not specific to arry of ttie above seven modules. These routines are collected into a design element referred to as 
the Model Engine Utilities 22, as shown in figure 1 . Exarrples of ttie Model Engine Utilities 22 include generic linear pro- 
gramming solvers, and statistical analysis routines. 

Tak>le 7 lists the modules in the DSS architecture for the two supply chains. 

55 
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Manufacturing Supply 


Equipment Repair Supply 
chain 


MarJcet Data Analysis 


Market Data Analysis 


Sales Forecasting & 
Planning (SFP) 


Sales Forecasting & 
Planning (SFP) 


rinisnea ijOOus 
Inventory MeUiagement 


rlXlXSneci VjOOuS xxivciii.ox:y 

Management (FGIM) 


Aggregate Production 
Planning (APP) 


Aggregate Production 
Planning (APP) 


PnrmDonent Prociurement & 
Policy Development 
(CPPD) 


ComDonent Procurement & 
Policy Development (CPPD) 


Vendor Managed 
Replenishment (VMR) 




Finished Goods 
Distribution Network 
Design (FGDND) 





Table 7 

Modules in the Manufacturing and Equipment 
Repair Supply Chain 



Market Data Analysis (MDA) 134 

The MDA Module 1 34 contains quantitative models and computational routines that compile and synthesize hybrid 
sources of market information to support Sales Forecasting & Planning, and VMR. The models and routines of the MDA 
Module 134 are used in support of Demand Characterization, Bottom-up Forecasting, Top-down Forecasting, Sales 
Promotion Analysis and Vendor Managed Replenishment The models and the routines in this module are used to: 
Analyze relevant iridustry data from vark)us sources; and Provkie quantitative analyses cfsal^ 

Scope arxi objective 

Objective: Compile and synthesize hybrid soiffces of market informatbn for the purpose of sales forecasting and 
planning, arxi VMR. 

Scope: Industry-wkie, company spedfk; arxi point-of-sale data. 

Features: Analyze relevant irxiustry data from sources such as Nielsen arxi El A (Electronk^s Industry Assodatkxt); 
Devek)p customer arxi customer^>roduct profiles; Maintain promotkHi calendars of major customer arxi the enterprise; 
analyze promotkxial elfects; arxi Provide c^jantitative analyses of sales at retail outlets whenever point-of-sale data are 
availabia 

Demand Characterization 

The rrxxiels arxi routines in the MDA 1 34 module to support demarxi cfiaracterization in the comn^dal setting are 
equally applicable to support requirements characterizatkHi in the defense setting. 

For national defense applk^ations. the actual repair item usage data correspond to the POS Data 138 in the com- 
mercial setting. Analysis for POS Data 1 38 can be perfbmned on the repair item usage data to characterize demarxi for 
various parts. Furthermore, in order to intuitively access relevant repair item-related data arxi infbrmatk>n, the relatk)n- 
sh^ arrx>ng different parts has to be established. To that end. we will develop a tree structure to represent the bill of 
material where each node of the tree corresponds to a repair item, and each arc represents a parent-chiki relationship. 
For ease of presentatkxi we empk)y convnerdal nomenclature in the follcwing section. 
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Analysis Routines for Demand Characterization 

In the foUowing. we descrbe three types of analyses that will be performed on industry sun^ey data. Demand His- 
tory Data 136, and Point-Of-Sales Data 138 to characterize the demand for the products (or sennces in defense appG- 
5 calions). There are other types of arialysis that can be performed on these data sets which w^^ 
when each individual data set is k>eing consid^ed. 

Product Family Composition Trend and Percentage 

10 This involves the analysts of the trends in quantity and percentage of each product family over a given period of 
time of the time series. The input of the analysis routine the set of time series corresponding to the product families 
and the associated product family names. The output is the trend of the quantity, and composition percentage for each 
individual product family. For example. Table 5 below provides the percentage changes for major color television prod- 
uct families (13"-14", 15"-24", 25", 26" and 2r & above televisions) from 1988 to 1994. 

IS 





13*- 


15 


It ^ 


2^- 


^6" 


i7 


* + 


1968 


24.76* 


55. 


87* 




1.14* 


6. 


T8¥ 


1989 


24.98% 


54. 


86i 


7.26* 


^.01* 


7. 


87* 


1990 


22.12% 


54. 


79% 


8.06% 


4.56% 


10. 


47% 


1991 


23.08% 


49. 


53i 


10.53% 


3.90% 


12. 


9^* 


1992 


20.62% 


48. 


18* 


13.29% 


3.40% 


14. 


51* 


1^9i 


19.13% 


45. 


12* 


15.87% 


2.10% 


17. 


76* 


1994 


18.57% 


41. 


58% 


17.58% 


1.55% 


20. 


71* 



^ Table 8 

Sample Product Family Composition Change from 1988-1994 

30 

Pareto Analysis of Sales 

The analysis involves the plotting of the percentage cumulative sales levels vs. the percentage of total number of 
35 products to determine the ABC classification of each product as illustrated in figure 29. 

Objective 

To identify tfie products or customer that contribute the most to the overall sales or production voluma To establish 
40 the ABC classification of products (or custonrters). 

Input 

POS Data 138, Shipment or production data. 
Output 

Plot of the currtilative percentage sales (or production) levels vs. the percentage of total nurTt>er of products or cus- 
tomer generating this sales (see figure 29). 

so 

Algorithmic Steps 

Rank products or (custonters) in deaeasing order of sales. 
Starting from the top of the fist corrpute: 

55 

curruilative sales 

cumulative number of product (or customers) 

Plot percentage of cumulative sales as a function of percentage of total number of products (or customers). 
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In addition, another scatter plot can be drawn to show the volatility vs. sales (where measure of the volatility is the 
coefficient of variation) as shewn in figure 30. Each point in the secorKi plot corresponds to a product (or product family), 
and the result of these two plots can be used to develop differentiated inventory control policies for products with differ- 
ent demand patterns. 

5 

Correlation Analysis AnrK>ng Prockict Families 

This involves the analysis of the con-elation among the time series corresporxfing to different product familieSw The 
input of the analysis routine is the set of time series corresponding to the product families and the associated product 
10 family names. The output is the correlation coefficient for related product fantilies. 

Industry Survey (EIA) Data 

Electronics Industry Association (El^ collects nrianufacturer to retailer Demarxl History Data 136 monthly from all 
IS m^or consumer electronics manufacturers. After consolidation by EIA. the data are sent back to the manufacturers for 
their own usage in analyzing industry wide sell-in activities. The data may t>e obscured t)y temporary stocking arxi other 
short-term dealings t>etween individual manufacturers and retailers, and they are usually a few nrK)nths late. Therefore, 
the data are normally not suitable for short term demand characterization and forecasting. However, for loriger term, the 
data are useful in revealing trerxte and changes in the sales of overall arxJ irxiividual product families. The three types 
20 of analyses described herein can be performed on the E lA data to monitor the long-term demarxJ level arKi composition 
changes^ 

Demand History Data 

25 Not all retailers are capable of collecting and providing the POS Data 138 to their manufacturer suppliers. For this 
reason, nrK>re traditk>nal Demand History Data 136 should be analyzed to characterize the demand for the manufac- 
turer's products. We realize that the demand data are a reflection of the customer demand but they can be altered by a 
number of factors. For instance, meeting the quarter-end sales target or taking advantage of temporary sales pronfK>tk)n 
deals may make true consumer demand for the products less apparent. Nevertheless, the Demand History Data 136 

30 are an important source of demand information that can complement the short term demand information from the anal- 
ysis off POS Data 138 and the long term demand informatkxi obtained from EIA data. In general. Demand H^tory Data 
136 are nrK>re suitak)le to arialyze the nDedlum term sales level and trend information. The three analysis routines 
described herein can be applied to the Demand History Data 136 to derive the medium term sales level and trend 
change inlormatk>n. 

35 

Point-of-Sales (POS) Data 

Major retailers are now collecting the sales transactkm data from the scanners at the sales counter and sending 
tfie data to their nranufacturer sufipliers after summarizatkm. The data drecUy r^tect the cor^mer demand for the 

40 manufacturer's products and response to sales promotions. They can serve as signals to the changes in sales trerxl 
and consumer reacttons to marketing efforts. In essence, the POS Data 1 38 can be used to detect short term sales lev- 
els arxi their charges for the manufacturer's products at various retaitirtg outlets. The three types of analyses descrit>ed 
herein can be performed on the POS Data 138 to nvmitor the short term demarxl levels and their ongoing changes. 
The inventory status represented in the POS should be verified In order to be used to assess the supply chain fin- 

45 ished goods Inventory situation. Shipment quantities from the manufacturer to the retailer are determined by consumer 
demand, and retailer's inventory carrying policies, among other inHuential factors while the POS Data 138 are much 
more direct in reflecting the true consumer demarxl. The folk)wing three analysis routines will be applied to POS Data 
1 38 in addition to the three general ones mentbned herein. 

50 Inventory Status Verifk»tkxi 

To verify the inventory status, the POS Data 1 38 can be used in combination with the shipment data, and the inven- 
tory t>alance equatkni to compute the deduced inventory status. Then, the deduced inventory status can be compared 
to the reported inventory status. 

55 

Inventory Proffle 

The inventory profile corresponds usually to the management decision of an organization, and can t>e used to 
judge the over- and under-stocking situation along the supply chain. The nomial inventory profile for each product and 
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10 



customer combination will be captired and stored so that it can be later retrieved arxJ compared to the current and 
future (projected) inventory profiles to determine the possAAe ever- and under-stocking situations. 

Detection of the Changes in POS Data 

The normal sales levete and associated variance intervals can be either calculated from the POS Data 138 for a 
given product b/ a customer, or specified by a user who is knowledgeable about the sales activities for the product. 
When the sales level fluctuates b^ond the normal sales variance intervals, the tool can detect and report the excep- 
tions automatically. 

Volatilrty of demand 

Objective 

15 To measure the volatility of demand. The volatility of demand can k>e measured by the coeff icierrt of variation of the 
demand. The coefficient of variation of a random variable is equal to the ratio of the standard deviation to the mean. A 
large value of the ooeffictent of variation indk^ates that the starxiard deviation is larger tfian tfie mean; the demand is 
therefore very volatile. While a small value of ttte coefficient of variation indicates a stable demand (kiw levels of vola- 
tility). 

20 

Input 

POS Data 1 38 or Shipment data by product (product group) or customer (customer group) 
25 Output 

Volatility measure Cs- 
Algorithmic Steps 
Compute mean of demand: 



30 



35 



40 



Compute starxiard deviation of demand: 



45 

Compute coefficient of variation: 



so o 



C =—2 



Lumpiness of demand 

56 

Objective 

To measure the I wel of lumpiness of demand. The lumpiness is a measure of the time disper&k>n of demand. A 
demand pattern is sakJ to be lumpy when the demand is corKentrated in only a few number of time periods with numer- 
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ous periods with no demand. 
Input 

5 POS Data 138 or Shpment data by product (product group) or customer (customer group) 
Output 

Ci the lumpiness measura ^ 

10 

Algorithmic Steps 

Ci = the percentage off the total number of time periods with demand equal zero. 
15 Demand pattem changes 
Objective 

To detect rapid changes in level and variat)ility of sales. 

20 

Input 

POS Data 1 38 or Shf>rnent data by product (product group) or custonr)er(custonriergr^ 
Range for "normaT sales level and variability. 

25 

Output 

Exception signal indicating a normal char>ge in sales levels. 
30 Algorithmic Steps 

Compute normal sales levels and associated variance from the POS Data 138 for a given product by a customer. 
Attematively user sets range for normal sales level arxJ variability. 
Compute actual level of sales and variance each period. 
35 When the sales level fluctuates t>eyorKl the normal sales variance intervals, detect and report the exceptions. 

Demand history trerxi 

Objective 

40 

To characterize demand by trerxi and level parameters. To assess changes in the dynamics of demand based on 
changes in trend. 

Input 

45 

POS Data 1 38 or Shipment data by product (product group) or customer (customer group) 
Output 

so Estimation of trend and level. 
Algorithmic Steps 

For variable Xt over time period 1=0 to n. 

55 



38 



EP0770 967A2 



Conpute trend (b) and level (a) param^ers: 



Jb=J3 5^ (i-t+J3)Xj-J3 



TO 



a*=lX-jb(n+l)/2)/ 



„2(„*l)i2i^.„2jnill 
6 4 



75 



MODEL 


WHERE USED 


Volatility of demand 


Demand Characterization 

PSI 

VMR 


Lumpiness of deniouid 


Demand Characterization 

PSI 

VMR 


Demand pattern changes 


Demcoid Characterization 
Bottom-up Forecast 
Top-dovm Forecast 
VMR 


Demand history trend 


Demand Characterization 


Pareto analysis 


Demand Characterization 
PSI 



20 



25 



30 



Usage of MDA Models 



Sales Forecasting and Planning (SFP) 132 

35 The Sales Forecasting and Planning Module 132 contains all the nxxlels and routines that are used to generate 
fbrecastSw These nrvxlels arxi routines are used in the Demand Management Franne 130 for Bottom-up, Top<k3wn fore- 
casting, for the analysts of sales pronations and to estimate forecast accuracy. The SFP Module 1 32 is also used in the 
VMRFirame250. 

The models arxl routines of SFP 132 fall into three categories: generic nrxxiels common to the manufacturing and 
40 repair environments; nrvxlels specific to the manufacturing environment; and nrxxiels specific to the repair environment. 

Scope and objective 

Objective: Develop top-down and bottonrHJp sales forecasts. 
45 Scope: Products and selected customers. 

Features: Statistical forecast t>ased on historical sales; Statistical forecast based on point-of-^le data if warranted; 
Customer provided forecast and orientations; and RecorKtliation tools to support expert judgment such as excep- 
tion flags and sanity checks. 

50 Models Corrvnon to Manufacturing and Repair Environments 

Three types of generic models are common to the manufacturing and repair environments. The first type consists 
of tiie various statistical forecasting models that can be used to forecast any time series (demand or consolidated 
requirernent). The second type concent the estinration cf seasonality factors bas^ 
55 repair and the manufacturing environments. The third type of model relates to forecast accuracy estimation. 

Statistical Forecast Models 



The objective of the Statistical nxxlels is to generate a forecast based on the projection of some hi^ical charac- 
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teristics dt the time series. These models can be applied to any time series In the context of demand characterization, 
bottom-up, top^own forecasts and VMR. 

Below we discuss the following models: Moving average; Linear trend; Exponential snKX>thing; Holt-Winters model; 
Winter's method; Regression based forecasting model; and Autoregressive/moving average nKxi^ (Box Jenkins). 

5 

Moving Average 

This conventional model is appropriate when the dependent variat)le Is assumed to fluctuate around a constant 
(stationary average value, i e.: 

10 

Xi = p + e,,t='1,2,... 

where p is an unknmvn constant corresponcfing to the mean of the series and Cf is a random error with mean zero and 
variance o^. Moreover, the model assumes that the variables {eJ and hence { are independent 

15 

Input 

Ttme series data to be forecasted (for example POS a shipment) 
Window n: numt>er of periods to be considered for averaging. 

20 

Output 

Future forecasts and their variarx^esw 
25 Algorithmic Steps. 

Conpute next period forecast leased on the average of the last n periods 



30 

35 Estimate for : 



- t 



var (F,^i - X^i) = a^(n+1)/n. estimated by a^((m.1)/h) 

45 

Linear Trend 

This conventional nxxiel is appropriate when the dependent (forecastable) variat)le is assumed to fluctuate arourvi 
a trend line, specified as a lirtear formulation of time, La sa-i-bt-f e, where et is a rarxk>m error with mean zero arxJ 
50 variance o^. As above, {ct) and hence {XJ are assumed to t>e independent The nfK)del may be vie^ 
of the regression based models below, with Hme' as the only explanatory variable . 

Input 

55 Time series data to t>e forecasted (for example POS or shipment) window n. 
Output 

Future forecasts and their \ariances. 
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Algorithmic Steps. 

Select appropriate time period for trend estimation (the "wirxiow" of n periods). 
Conrpute trend and level parameters: 



a2=|X-jb(i3+l)/2]/ 
Estimate forecast based on trend projection 



6 4 



Fj^i =a+b(t+1) 

Estimate variance of forecast 



Exponential Snrxxjlhtng 



This conventional model is appropriate when the dependent variable is assumed to fluctuate around a constant 
(stationary) average value, i.e.: 

X, = p + e,.t=:1A... 
It puts progressively smaller weights on nfKjre remote observations from the past: 

F,^i = aX, + a(1-a)X,.i + a(1-a)^ X,.2 + .... 

Input 

Time series data to be forecasted (for example POS or shipment) 
Smoothing parameter a 

Output 

Future forecasts and their variances. 
Algorithmic Steps. 
Initiate Fi as Dq. 

F,^1 =aD, + (1-a)F^. 

Estimate variarice of forecast 
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Estimate variance of forecast error = Var (F,^i - X^^^) = (a^) V(2-a) 



Hott-Winters model 



70 This conventional model is appropriate when the dep^xtent (forecastable) variable ts assumed to fluctuate 
around a linear trend line, i.a when is specified tjy: 

X, =a + b.tf e, 

75 with the associated assumptions regarding e. As with exponential smodhing, pro^essively smaller wights are attrib- 
uted to more remote observations. 

Inputs 

20 Time Series Data to be forecasted (for example POS or shipment). 
Smoothing parameters 1>a^>0. 

Outputs 

25 Future forecasts and their variances^ 

Algorithmic Steps 

Initial So and Qo* intercept anid slope of trend lina 
30 Update recursively 

S, = ~aX, + (1-a)S,.i +Gj.i 
Gt = P(S,-S,.i) + (1-p)G,.i 

35 

Set 

^ Ft+.= St+'^Gt 

= aD^ + a(1+p) (1-a) X^^ + a(1-a) (1-a-aP) X^.^ + a(1-a-ap) (1-a)^ X^.3 + a(l-a-ap) (1-a)^X,^ 

VSar (F,) = a^{a^ + (1+p)^ (l-a)^ + a(1-a-ap)^(1-a)^/(2-a)) 

45 

Estimate ^ance of forecast 



so 



Estimate variance of forecast error by: 

55 



Var (F^, - D^i) = {1+a%(1+p)2 (1.a)%(a(1-a.ap)2(1.a)2V(2.a)) 
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5 



Winters method 

Ihts conventional nrvxJel is appropriate when the dependent (forecastable) variat)le is assumed to fluctuate around 
a linear trerKl line modulated by seasonality factors. I.e. 

X, = (|i+G,)Ct + e, 

^ is the initial deseasonaBzed level, G the trend or slope component and Ct the multiplicative seasonality factor. Assume 
that the season consists of N periods. La c, - for all t. The seasonality factors are normalized such that: 



10 



75 Winters* method uses three smoothing factors, a, p and yas follows: 
Inputs: 

Time Series Data to be forecasted (for example POS- or shipment). 
20 Season length N. 

Smoothing factors, a^pandy. 

Outputs 

25 Future forecasts and their variances. 
Algorithm Steps 

Step 1 : (Initialization). Use first two seasons (periods - 2H^^ , -2r442,....0) to initialize values: 
la: Calcdate sample means for two separate seasons of data. 



30 



3$ 



40 



55 



E 



1 b: Define Gq = (V2 - V1)/N as the initial slope estimate. 
1c: Set So = V2 + as an estimate of the value of the series at time t=0. 

45 Id: (Compute initial estimates of seasonal factors; ttiese are obtained t)y dividing each of the initial ot>servations 

by the corresponcfing point on the line connecting and V2. i.a. confute: 

C, = X4(V| - (NM.1)/2h)Go]. i = -2W^.1,...,0 

50 1 e: Average seasonal factors as computed for the two seasons 



If: Normalize seasorial factors: 
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5 

Step 2: Update recursively: 

= a(X/C,^) + (1-a) (X,.i+ G^.^) 
G, = p[S,-S^.iI + (1-p)Gt., 
C, = Y(Dt/S,) + (1-T)C,.N 
75 Step 3: Create forrard forecast in period t for period t+x: 

Regression based forecasting models 

20 

In this conventional model, it is assumed that the forecastable variat)le X vs determined by exogenously 
measurable (forecastable) variables Z^''^ Z^,...Z^) as follGws: 

X,=a + b,z(^>, + b2Z«.+...+ b„Z^'">, + e. 

25 

where {ej are indeperxient with mean zero and variance o^. 
Inputs 

30 Time series for {XJ and all explanatory variables Z^V -.^^""^ For example market share, total market value, 
installed base, GNP. etc. 

Time series data to be forecasted (for example POS or shipment) 

Outputs 

35 

Estimates of coefficients a, t>i, bz b^ as well as o^. 

Forecast for future value of X. on the basis of estimated future values of 2f^\ Z^\....z("^). 
Algorithm Steps 

40 

Use of standard multiple regressfon metfiod. 

Autore^'essive / Moving average nxxiel (Bex Jenkins) 

45 In this category of models, it is assumed tfiat the forecastable variable {XX} exhibits an autocorrelated structure. The 
most general nrvxlel of this type is specified as an ARMA (p^q) 
model. i.e. 

X| = P 1 X|.i + p 2 X,.2 +...Pp X|^ + e, 

50 

Where 

55 with {uj independent with mean zero and variance o^. 
Inputs 

Time series data to be forecasted (for example POS or shipnr^). 
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Outputs 

Identification of optimal values of p and q. 

estimates of coefficients p i pp and y i Yq as well as o^. 

5 Forecast of future valua 

Algorithmic Steps 

Standard Box-Jenkins Algoritfim and Process witfi forecasted value corrputed as follows: 

10 



IS 

Seasonality factors estimation 
Objective 

20 

To estimate fior each time bucket (quarter, montfi, week) its percentage of the yearty votuma 
Input 

25 Historic data by aggregated at the same level as the seasonality 
POS 

Shipment 

Total market volume, eta 
30 Output 

Seasonality factors for each time bucket. 
Algoritiimic Steps 

35 

Conpute for each time txjcket the proportion of the yearly volume it representSw 
Forecast Accuracy Models 

40 To estimate the accuracy of the various types of forecasts. Measures of forecast accuracy are used in various con- 
texts. 

It is a proxy rneasure for the variarK^cl the forecast when this one cannot directly be con^^ Forecast variance 
is used in several inventory and safety stock cateulations. 

Forecast erra measures can also be used to identified those products and customers for whrch demand patterns 
45 are particularly unstable and thus require special attentioa 

Forecast error catoulation 

Objective 

50 

To compute forecast error for the forecast produced n periods ahead. 
Input 

55 Actual Sales 

n periods ahead Sales Forecast (BU, TP, etc.). 
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Output 

Average Absolute Error as of percentage 
Mean Square Erra 
5 Table off forecast accuracy as function of n 

Algoritfimic Steps 

Corrpute the percentage difference t>etween the forecasted and actual sales. 
10 Compute average absolute error and mean square forecast error. 

Exception report generation 

Objective 

IS 

To generate the list of the products or customers for which the forecast error was greater that a predetermined fore- 
cast error threshold. 

Irput 

20 

Average Absolute Error 
Mean Square Error 
Forecast error threshold 

25 Algorithmic Steps 

Rank fist in decreasing order of Average At)solute Error or Mean Square Error 

Output 

30 

Exception list ordered list of products for which the forecast error was higher than the threshold 

Models Specific to the Manufacturing Environment 

35 The particular aspects of the manufacturing environment call for specific models in the area of forecasting and plan- 
ning. In particular a forecast approach that specifically models the ordering pattern of retailers based on their replen- 
ishment policy and level of sale to the final consumer is considered. Approaches for the modeling of sales promotions 
are also proposed. 

40 Expert based model for Bottom-up forecast 

This discussion descrfoes an algorithm to compute txittom-tp forecasts designed so as to result in the k>est avail- 
able point estimates off sales as well as a cffiaracterization off the degree off uncertainty surrounding these estimates. 
The system develops forecasts for each account, each model and each time-period. These are subsequently aggre- 

45 gated over all accounts. 

The analysis starts with a cffiaracterization of the accounf s anticipated sales pattern for a given model. Its order to 
the manufacturer are obtained as derivatives of this sales pattern, assuming that a specific systematic replenishment 
poficy is followed k>y the account The prevalence off a systematic replenishment policy On the absence off capacity prot>- 
lems) is an important assumption but one which we have verified in our analysis off real retailer's behavorior. 

50 Prorious investigations off point-of-sales data have established that the accounts' sales pattern is much more pre- 
dictable and regular than tfra normal order stream. It is therefore appropriate to start the forecasting process with a 
characterization off the accowit's sales pattern. Moreover, we envision that the inputs to the system be provided by the 
retailer in cooperation with or as a result of monthly meetings with account representatives (buyers, logstics manag- 
ers). The account representatives are dearly more familiar with their sales pattern than the resulting order stream to 

55 their supplier; their estimates for future orders are clearly driven by their anticipation of future sales. 

The need to characterize the uncertainty of the manufacturer's model sales stems primarily from the fact that this 
characterization is to be used as the foundation for inventory planning, i.e. the determination off the so-called 1-line or 
lower bounds for the l-line required to assure customer service levels which are compatible with the manufacturer's 
Quick Response targets. 
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To assess minimum inventory requirements one needs to characterize cumulative sales ever tinr^e rather than or in 
addition to sales per month. Extreme care needs to be exercised in aggregating sales over consecutive months since 
these are highly correlated. Thus, a straightforward corM>tution of orders in consecutive months would lead to serious 
underestimates off the variakxiity of cumulative orders and hence to the determination of inappropriately low safety 

5 stocks (minimum inventory levels), exposing the manufacturer to undesirat^le frequent stockouts. These would result in 
inappropriate customer service, loss of market share and last but not least, a continuation of the vicious cyde prevent- 
ing the manufacturer from establishing reliable forecasts in the first place. 

Our approach provides an exact characterization of the statistical distrbution of cumulative sales based on a given 
characterization of the underiying sales pattern. 

10 The calciius used to characterize the dstributions of account orders and aggregate orders is k>ased on simple but 
rigorous prot>ability calculus. 

The system is intuitive and fully transparent to all users. Below we give a brief outline of the inputs required by the 
system and the user interlaces which we envision devek)pirTg to provide the user with various types of l>ackground infor- 
mation to facilitate the task of specifying forecast inputs. 
75 The calculus used to derive all order arid aggregate order distritxitions is explained. 

Required inputs; user interfaces 

The user will be responsi3le for entering forecasts for specific aocount/imodel comt>tnations under his/her respon- 
20 sft)ility l=6r arry given accountAmodel combination, forecasts are to be provided for the next 12 months on a rolling hori- 
zon basis. The user will t>e confronted with a main menu permitting a choice k)etween: (I) whether to provide estimates 
of the accounts' sales (II) or orders (12); and (II) whether to provide estimates of monthly total sales (orders) (111) or to 
provide separate estimates (112) for 

25 (a) regular sales activities, and 
(b) Promotional activities 

We will strongly eruxHirage LAMs to opt for 

30 (1) providing estimates for sales, and 

(2) providing separate estimates for regular arxl pronrKTtbnal sales 

H optkm (12) is chosen, the calculations desaibed t>elow will be circumvented and by default orders in consecutive 
nfxxTths will t>e treated as indeperxJent. (This may result in important distortions as explained in the introduction but is 
35 unavokiable under this option; the user cannot be expected to estimate the intertemporal correlation pattern. It is con- 
ceivable that an "average** oonrelation factor may be inferred from historical orders.) 

All accounts managed t)y the three LAMs wfiom we have interviewed follow or wouki like to follow a simple replen- 
tehment polk;y of the folkywing type: (a) the model's inventory position is reviewed periodically (e.g. once a weeK once 
in two weeks, once a month); and (b) at review epochs the account places an order to iricrease the nrKxJel*s inventory 
40 position to a target level of a given nunrter of weeks of future expected demands (&g. 6 weeks, 8 weeks) unless the 
current inventory positkHi is already atxive this target level in whk^h case no order is placed. 

The formulae betow are based on this type of replenishment policy which is characterized by two parameters only 
(the review period and the target order-up to level in weeks). This polk;y structure is easy to use and efrk^errt from rme 
tfian one point-of-view. Ktowever, it will be easy to make appropriate modifications should it become apparent that other 
45 types off ref^lentshment polkaes are used t)y some accounts. 

Inputs 

St sales in period t (rarKk>m variat)le) 

50 ^t= ES, 

W = number of perkxls of future demancte to which the inventory position is to be increased every time an order is 
placed. 

The disbixitk>n of St is obtained by fitting an appropriate distribution to the three point infornrtation provided by tiie user. 
55 We fit a shifted Binomial distribution: 

S^rnin ^ pfiinimum sales for period t 

Sx"^ = maximum sales for period t 

St"^^ =nrx>st likely sales volume for period t 
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Let s, = St -S,"**" and assume it is Binomial (ap) with n = St"™^ - Si"^ 

[np + (1-p)]+1 = s, e.g. p = (s'^^ 1^6,"^" -iyn 
5 ([x] - denotes the largest integer smaller than or equal to x) 
Outputs 

0| = order in period t 



10 



15 

o^ = cumulative orders in periocte 1,...,t 

IPt = inventory position at end of period t after plactr^ an order (= inventory on hand + outstanding orders) 
Tt = target order-up to level at end of week 

20 

w 



25 

The follGwing recursive relationships hold (assuming backlogging; the equations are easily adjusted for the cost of lost 
sales) 

30 IP, = IP^i-s^+|T,-IP,.i+sj'- (1) 

o, = |T,-IP,.,+sJ^ (2) 
Ot=o,.i+r,-IPM+s,l^ (3) 

35 

We assume here that the St - variat)les are independent of each other. 

Calculating IP, and o, - distributions 

40 The distrixition of the IP, - variables can be computed recursively. Observe the \Px~^ and s, are independent of each 
other. 

Prob[IP, = T J IP..1 = Q = Pr[s, ^ I - T J (4) 

45 Hence. 

Prob[IPt-TJ =- 



(5) 

55 

For r > T,. ProbllP, = r I IPh = 0 = Probls, = I - n 
Hence, 
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Prob[IPt = 1'] = 



53 Pxojb[JPt-ia<rt=-^l 'Prob[S^^l-l^] 

J=inax<re-l.I 



70 (6) 



IS Prob[o, = 0 1 IPj.i = q = Prob[s, ^ I - TJ (7) 



Prob[Ot -0] = 



2D 



Prob[St,^l'T^] Projb(JL.,i=l] 



5. 



£5 



(8) 

30 Calculating Cumulative Order Dtetributions 

The disbtxjtions of cumulative orders, i.e. the (Ot) - distribution can be computed recursivety as well but only by com- 
puting the joint cfistrbution of Ot.i and IP^.^ : 



35 



Case 1 Let k'>k: 

PrtO , = »^ and IP I = T J 0 1. ^ = k. IP = 0 = Pris t = - k + 1 - T ,1 (9a) 
PrtO^ = k-and IP^ = r 1 0^.i = k. IP^^ = 1] = 0 (9b) 

40 foralir^Tt 
Gase2k'=k: 

Pr[Ot = k and IP^ = 1' | O^-i = k and IPt-i = H = 

(pr[St=l-l'] if r^il'^l 
\ 0, otherwise 



45 



(10) 



50 



TTius 

PrIO, = k" and IP, = T J = PrlO^, = k, IP,.i =1]. 



£5 
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Pr[s, = k'-k*l-T^] * 52 Pr[Ot-i=^' and IP^.y = il Pr[s^l-T^] . 

1-1' 

PTlO^^k' and JPe=i1 

(11) 



10 

PrfO,.-, ^k-andlP,.! =11. 

P1s^ = l-n (12) 

IS 

Past Promotions Effects Estimation 
Objective 

20 To assess the totallnpact on sales of past pronrvitions. 

Promotions perturb the regular pattern of sales and various types of pronxitionat activities influence the sales vol- 
umes according to rather different patterns. The objective of the model is therefore to assess the pattern of the impact 
of the promotion over time. 

25 Inputs 

Times series of sales. 
Time period of the promotion. 
Class of the promotion. 
30 Typeof thepronrK3tion. 

Intensity of the promotion. 

Outputs 

35 Overall impact of the promotion 
Profile of the impact over time. 

Algoritiimic Steps 

40 The model is t>ased on the use of time series models First, an analysis is applied to a "censorecT time series of 
sales volumes, in which all promotion (and after promotion) periods have been eliminated. One of several basic time 
series models is applied to identify trend factors, seasonality indices and/or auto correlation structures.These basic time 
series models include exponential snrxxTthing (weighted) moving averages, Winters* nrKXIel, Box-Jenkins models. The 
Ibllowing Modified Winters* Procedure uses the demand (POS a shipment) data to remove seasonality and trend 

45 effects. 

Select time series model for estimation of dentand for norvpromotion periods. 
Initial Estimation of Level (including trerKl) at each Historical Period. 

Calculate the moving average of seasons, with each season having period P. If P is an even number, take the average 
of two consecutive moving averages to let the estimate centered on the time period. 

50 

Estimate Seasonal Fiactors. 

Divide the actual demand by the centered nrxyving average to obtain the estimate seasonal factor. Dampen the ran- 
dom effects by taking averages for similar periods in different years. Then, normalize the estimate seasonal factors that 
55 totals to R Using the normalized seasonal factors remove the seasonality effects from the demand data. 



Estimate Lev^ and Trend Terms. 



Using the regression equation algorithm specified in tiie MDA 134 module, find tiie regressfon parameters for level 
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and trend coefficients to fit the regression line. Using the regression coefficients renxive the trend effects from the 
demand data. 

After an appropriate time series model has t>een selected for all non-pronrxxtion periods, interpolate base-line sales vol- 
umes in the prorrxition periods which would have arisen in the absence of the special promotion activities. 
5 Calculate the ratios of the actual sales volumes during the promotion periods and the calculated "base line" values, for 
each proTTKition period separately. This defines ttte impact curve of the promotion. 
Aggregate the irnpact curves pertaining to different prornotkm periods of a given ty^ 
curve fitting techniques. 

The resulting impact factors for each of the periods t>elonging to svd following after a promotion irrterval can new 
10 be used in future forecasting efforts. 

Future Promotion Impact Estimation 

Objective 

15 

To estimate the irrpact of a future promotion 
Inputs 

20 Time period of the proTTKition 
Class of the promotion 
Type of tfie promotion 
Intensity of the promotion 

25 Outputs 

Estimated overall irrpact of. the promotion 
Estimated profile of the impact over tima 

30 Algorithmic Steps 

Search promotion calendar for past promotions with similar characteristics. 
Assess impact of the planned promotion t>ased on conputed effect of similar past promotions. 
Identify ger>eric prof ie of promotion impact corresponding to the planned promotion. 
35 Conrpute estimated profile of tfie planned promotion kiy combining estimated total irrpact arxJ generic profile. 

Analyze Promotion Effects 

This analysis includes the following three types of promotional activities: price promotions, wfiere the item price is 
40 reduced by a given percentage for a limited period of time (e.g. 1 -2 weeks); promotions via feature advertisements; and 
promotions via special store displays. 

The cfiaracterization of the impact of pronrxitional activities is to be used as the basis of the statistical forecasting 
procedures In the Forecasting module of our DSS 10. It will also be invoked as guiding information in the bottom-up 
forecasting procedura 

45 The sales promotk>n activities perturb the regular sales pattern in the commercial setting. Con^espondingly, special 
events such as scheduled exercise in the defense application will also significantly change the usage of parts. There- 
fore, the models devetoped for analyzing the effects of sales promotions will also be applicable in understanding the 
effects of the special events in the defense setting. In tfie folfowing section we enpfoy corrvnercial tenminology for ease 
of explanatfon, while the models are eq^ly applksble to both the defense and commercial appircations. 

50 It is tx>th intuitive and extensively substantiated by several statistk»l studies in the conventional marketing literature 
(see e.g., Blattberg and Maslin (1993)) that the various types of promotiorml activities influence the sales volumes 
according to rather different patterns. Price promotions typically result in a significant increase in the sales volume dur- 
ing the course of the promotion period. The increase in tfie sales volume is due to: 

55 a. consumers increasing their normal purchase quantities to take advantage of the terrporary price discourtts; 

bi consumers makirtg a purchase during the promotion perfod wfK> otherwise woukl fiave waited until a future point 
in time; 

c. consumers being enticed into a purchase wfK> otfierwise would have opted for a different brarxi or who othenwise 
would not k>e in the market for this item. 
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Only factor (c) results in a significant long term inaease of the sales voluma The first two fectors (a) arxi (b), on the 
other hand, cause an inaease of the sales volume during the promotion period, but the increased volume is partially or 
completely co mp en sa ted for by a decline in sales after the promotion period. 

Rgure 31 displays a typical pattern for the percentage increases over time, resulting from a price promotion. As 
5 mentioned, the percentage increase is positive during the promotion period; the magnitude of the impact first increases 
arKl then decreases. The promotion period may be followed by an interval of time with a negative tnrpact; the magnitude 
of tfie decline first increases arxJ then decreases. See Lewandowski (1985) for more detaila 

The impact of promotions via feature advertisements or special in-store display may exhbit a similar pattern (as 
in fi^re 18); alternatively the impact of these types of pronwtions may be confined to the pronrtotion period itself. 

10 

Regression Models 

Our menu of regression equations consists of variants of the following basic equation used in Blattberg and Wis- 
niewski (1988) and with minor changes in Wittink et al. (1987). 
IS Let: 

Sjt = Weekly retail sales for item 1 at time t 
Rj, =:The regular (shelf) price of item i at time t 

Pjf = The ot>served price (actually paid by the consumer) for item i at time t 
20 Djt = The deal discount for item i at time t ((Ri,-P^Fy, 

CPjf = The price of a competitive item j at time t with j not equal to i, 

Xit = A dummy variatsle which equals 1 if a cfisplay is run for item i at time t, 

Yjt =1 A dummy variable which equals 1 if a feature ad is run for item i at time t 

Lit = A variable representing deal decay, equaling lq-1 with j being the time since the t>eginning of the deal and 
25 0<k<1, 

The basic regressk>n model is: 

30 

All of the data required for this model are availat)le in our data sources. The only possible exceptions are the CPjt -num- 
bers which reflect prices charged for items provkied by competing vendors. We foresee tfiat the latter may not be avail- 
able in some commercial supply chain setting& If so. the item XjS^CPjt is eliminated from equation (1). On the other 
hand, a trend and seasonality factors (expressed e.g. via incficator variables) may be added to equation (1). For exam- 
35 pie, if the year isdivkied into four distinct seasons, add the variables Zh=1 if period t is part of season I (l»1>K, 3) (along 
with a trend term) to the right hand side of (1): 

S^=«xp{a^+pYlZij+Y2Z2(*Y3Z3^a2fl#+a3D^+a4X^+a5yy^+a6L^} (2) 

40 The log-linear formulation in equations (1) and (2) has been shewn to provide significantiy better precfictions than the 
simple linear formication. The spedfKation in the conventional Blattt)erg and Wisniewski nrxxiel implk^itly assumes that 
the impact of a promotion is restricted to the promotion period itself and that the magnitude of tiie impact exponentially 
declines over tin^ To allcw for a general pattern of impacts as in figure 30. we are considering the following variant Let 
denote an upper bound on the niAnl>er of periods over whKh a price promotion exercises a signif cant impact and let 

45 

Uh =1 if period t arises I perkxis after the beginning of the last promotion period. 
M.Ku 
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(3) 
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The coefficients of the above regressfon equations will be determined by using the generic regression routine specified 
elsewhere herein. 
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Time-Series Mcxiels 

An alternative approach to analyze retailer promotions is based on the use of time series models. Rrst an analysis 
is applied to a "censored* time series of sales volumes, in which all promotion (and after promotion) periods have been 
5 eliminated. One of several basic time s^es models is applied to identify trend factors, seasonality indices and/or auto 
condition structures. These basic time series models Include exponential smoothing (weigfited) moving averages, Win- 
ters' model. Box-Jenkins models. The following Modified Winters* Procedure uses the demand (POS or shipment) data 
to remove seasonality and trend effects. 

10 Step 1 . Initial Estimation off Level fmcluding trend) at each Historical Period. 

Calculate the moving average of seasons, with each season having period P If P is an even number, take the aver- 
age of two consecutive moving averages to let the estimate centered on the time period. 
Step 2. Estimate Seasonal Factors. 

Divkie the actual demand by the centered moving average to obtain the estimate seasonal factor. Dampen tfte ran- 
75 dom effects by taking averages for similar perkxte in different years. Then, normalize the estimate seasonal factors 
that totals to R Using the normalized seasonal factors remove the seasonality effects from the demand data. 
Step 3. Estimate Level and Trend Terms. 

Using the regresskm equation algorithm specified elsewhere h^ein, find the regressk)n parameters for level and 
trend coefficients to frt the regresskm lina Using the re^'ession coeffk;ient& remove the trend effects from the 
20 demand data. 

After an appropriate time series model has been selected fa all non-promotion periods, one can interpolate the so- 
called base-line sales volumes in the promotion periods which would have arisen in the atsence of the special pronrK>- 
tion activities. By calculating the ratios of the actual sales volumes during the promotion periods and the cakxilated 

25 l>ase line" values, one constructs an impact-curve as in figure 31 for each promotion period separately. The impact 
ounces pertaining to different promotion p^ods of a given type can next be aggregated into a single curve i^ng stand- 
ard curve fitting technk|ues, see figure 32. The resulting irrpact factors for each of the periods bekmging to and foUow- 
ing after a promotion interval can rK>w be used in future forecasting efforts, as guxied tyy our F=brecasting Modul& The 
approach follows that of Ak>raham and Lodish (1992) wfK> have successfully adopted the nDettKxk)k)gie8 in their eariier 

30 PROMOTER system to arvilyze retailer promotbns. The PROMOTER model has four primary steps: (1) adjustment of 
tfie data for trend, seasonality, (2) elimination of data points Influenced by promotion, (3) extrapolation of data points not 
influenced t>y pronxstion into promotion period, and (4) computation of promotion effect as tiie difference between tiiis 
baseline and actual sales. 

35 
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MODEL 


WHERE USED 


Statistical forecasting models: 

• moving average 

• trend 

• smoothing models 

• Holt Winters model 

• Winter's method 

• Regression based 
forecasting 

• Au uoregre 8 s 1 ve / 
Moving average models 


Demand Chauracterization 
Bottom-up Forecast 
Top-down Forecast 

VMR 


Expert based forecasting model: 


Bottom-up Forecast 


Seasonality factors estimation 
routine 


Demand Characterization 
Bottom-up Forecast 
Top-down Forecast 
PSI 
VMR 


Forecast accuracy routines: 

• Forecast error 
calculation 

• Exception report 
cr^ner at ion 


Bottom-up Forecast 
Top-down rorecasu 
PSI 
VMR 


Past promotions impact 
estimation model: 

• Regression model 

• Time series model 


Sales Promotion Analysis 
Bottom-up Forecast 
Top-down Forecast 


Future promotion impact 
estimation model 


Sales Promotion Analysis 
Bottom-up Forecast 
Top-down Forecast 



Table 10 
Usage of SFP Models 



Models SpedHc to Repair Environment 
Definitions 

Equv>ment consists of modules that are composed of reparable items, and repairat^le items are made of corrpo- 
nents. 

Requirement: failure of an equipment 

Consolidation policy: the policy of repladng the defective reparable item of a failed module with a good reparable item 
of an already defective module and reinstalling into the equipment 

Defective ratio: ratio of numt>er of defective reparable item to the total numt>er of reparat)le items in a module. 
Target level: maximum defective ratio acceptable before a module can be sent back from the equipment location to the 
repair depot The target level is one of the two parameters of the consolidation policy. 

Raw requirements (pre-consolidation requirements): total requirements generated by all equipment at the equipment 
location 

Consolidated requirements (post-consolidation requirements): requirements for equipment after consolidation policy is 
applied to raw equipment requirements (number of modules sent to repair depot for repair from the equipment location) 
Raw Requirements Estimation (for Bottom-up estimation) 

Objective 

To estimate raw requirements for all equipment located at a particular equipment location based on the planned 
activity (usage) schedules of the equipntent 
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Input 

Equipment located at the equipment location. 

Activity schedules for all the equipment at the equipment location such as: 

5 

equipment upgrade/htaintenance schedules (preventive and breakdown maintenance schedules) 
activities (i.a, operation time, number of setips. cumulative operation time) 
planned activity schedules for all equipment at the equipment location 

10 Output 

Estimations of the raw requirements for each equipment at the equipment location 
Algorithmic steps 

Establish relationships between raw requirements and activities of the equipment based on analysis of graphs, etc. 
Analyze the effects of activities on requirements using regression or time-series nKxJels 

Estimate raw requirements for each equipment given the equipmenfs planned activity schedule by tfie models used 
above 

20 Consolidated Requirements Estimation (for Bottom-up estimation) 
Objective 

To estimate consolidated requirements for all equpment located at an equipment location based on the estimated 
25 raw requirements 

Input 

Estimated raw requirements for each equipment at the equipment location and the time of requirement 
3o Batching parameter for the batching policy of the equipment location 
Consolidation policy (target level and the search rule) 
Inventory positions at the equipment location for modules and reparable items 

Performance measures: stock level, service level (availability of equipment), repair cost associated with repair at 
equ^>ment locations and the repair depot 

35 

Output 

Estimates of consolidated requirements for all equipment at an equipment location 
Values of performance measures 

40 

Algorithmic steps 

Search under consolidation policy 
Identify repairable itenris to be sent to repair depot under t>atching policy of the equipment location 

45 

Consolidation Policy 

A consolidation policy consists of two elements: a search rule for sheeting tfie defective repairable item to be con- 
solidated, and a target level, that is the maximum defective ratio acceptable before a nrxxJule can k>e sent back from the 
50 equipment location to the repair depot. 

Given a newly failed module of type I with a defective reparable item of type j, the consolidation policy defines which 
reparable item should be chosen out of which nxxkile to perform the consolidation. The chosen repairable item should 
already be part of a nrnxlule wrtti at least one defective reparable item but containing a good component of type j. The 
search rule select the reparable item for consolidation among all such defective nuxlules. The foltowing search rules are 
55 consklered: 

Carry out the search for defective modules of type I only. Sort the defective modules of type I in decreasing order 
of the defective ratio and starting from the top of the list, select the first moduletfiathasagoodcomponentjinit if one 
eodsta If not, sort all the other defective nKxiules in deaeasing order of the defective ratio and starting from the top of 
tiie list, select ttie first rrKxlule ttiat has a good reparable item j in it if one exists. If not, (consolidation cannot take place) 
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replace the failed module I with a good one. if one is available at the equipment location. If not, equipment becomes 
unavailable until either a consolidation or a replacenoent can be made. 

Determine all nxxJule types for which slocks of good items at the equipment location are below a threshold value. 
Sort the defective modules of all such types in decreasing order of the defective ratio and starting from the top of the 

5 list select the first module that has a good reparable item j. if one exists. If not sort all the other defective modules in 
decreasing order of the defective ratio and startir>g from the top of the list, select the first module that has a good repa- 
rable item j. if one exists. If not (consolidation cannot take place) replace the failed module of type I with a good nrxxlule 
of type K if a good one is available at tfie equipment kx:ation. If not the equpment becomes unavailable until either a 
consolidation or a replacement can be mada 

10 Sort the defective modules of all types in deaera'ng order of thedefective ratio and starting from the top of the list, 
select the first module that has a good reparable item j in it if one exists. If not (consolidation cannot take place) replaoe 
the failed module of type I with a good one, if one is available at tiie equipmerrt location. If not equipment becomes una- 
vailable until either a consolidation or a replacement can be made. 

15 Batching Policy 

The batching poficy is defined by the size of a batch, TH1, (TH1 can be equal to 1). The inventory policy is in the 
form of: count the number of defective rrxxiules with defective ratio greater than the target level. If this number is greater 
than THI . then serKi T1-I1 units of repairable items to the repair shop else rait until this condition is satisfied. 

20 

Consolidated Requirements Estimation (for Topdown estimation) 
Objective 

25 To estin^e consolidated requirements for all equipment located at a particular equipment location t>a8ed on his- 
torical data 

Input 

30 Time series of consolidated requirements for each equipment locations. 
Output 

Estimates of consolkiated requirements for all equipment at an equipnient kx:ation 

35 

Algoritiimic steps 

Use a converrtional Kalnnan fitter based algorithm and convention 
solidated requirement fa the equipnient 

40 

Determining a repair plan 
Objective 

45 To determine a repair plan based on aggregate repair plan, and repair constraints (resource capacities and k&jf 
component availat>ility) 

Input 

50 Aggregate repair plan 

Available resource capacities anti degree of f lexbility to change resource capacities 

Key component availatMlity (projected inventory positions, supplier and lead time information, inventory replenish- 
ment policy) 

55 Output 

Repair plan for the repair shop that is feasible with respect to the repair constraints (capacity arxJ key component 
availability). 
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Rnished Goods Inventory Management (FGIM) 164 
Scope and objective 

5 Objective: Decide where to stocK how much and when to replenish in (hybrid) made-to-stockMiade-to^rder envi- 
ronment 

Scope: Single and dual echelon. 
Features: 

Single and dual echebn inventory models for how nuch and when to replenish stocking points. Cost vs. service trade 
10 offis to determine where to stock. 
Deployment 

Models specific to manufacturing environment 
Overview 

75 

Objectives 

This module contains a collection of fhished goods* inventory models enabling the selection and evaluation of 
Inventory policies. The nrKxiule r^ms an I- and P- line extended to a given horizon (of T periods) beyond the cun-ent 
20 period. At this stage, all of the models represent setting where any given item is distributed to the o^tomers from a 
single k)cation. 

Input 

25 Forecasts of niean demancte per item, per period (8* line) ; standard deviations of demands per period per item (a* 
line); mean production lead times for each period per item (U line); standard deviations of lead times for each period, 
per item (V line). 

Output 

30 

Inventory (I) line 
Production (P*) line 
Inventory strategies 

Models are classified as follows: Ml. Models with Non-Lumpy Demand; and Mil. Models with Lumpy Demand. Lumpy 
35 denftands refers to settings where demands are sporadic or experience extreme variability. The demand process for a 

given item will be dasstfied as lumpy if the percentage of zero demand periods or the coefficient of variation of the 

demands is above pre-spedf ied critical levels. 

Within the category Ml we next differentiate between: Mt.1 Models managing inventories or on an itenvby-item 

basis; and MI.2 Multi-ftem models wHh joint capacity constraints. 
40 The choice between these two categories depends on whether or not irrportarrt interdependenctes prevail between 

the rtenrts (in the form of joint capacity constraints or joint cost structures). Within each of the subcategories MI.1 and 

MI.2, different nxxlels can be selected based on the extent to which policy paranieters are to be pre-spedfied by the 

user or computed based on an appropriate tradeoff between cost and service measures. 

45 Ml Inventory Models for fston-Lumpy Demand 

MI.1 Models for Independent Items 

As mentioned above, in this category inventories are managed on an item-by-item basis. Different rrxxiels need to 
50 be invoked dependent upon the extent to which policy paranrieters are to be specified by the user. Alternatively, the 
nrxxiels to be used can be determined endogenously based on an appropriate tradeoff analysis or optimization of vari- 
ous cost and service measures. 

MI.1 .1 User-Specified Base-Stock Pdides 

55 

Objective 

In this model, the user spedties an order-up-to or base-stock level as a given nurnber of weeks of in^ Based 
on this inventory policy, the mode) projects out an rand P* line for a scenario in which tine forecasted mean demands 
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are realized. 
Additional Inputs 

The desired t)ase-stock level for each period 

nt = nunnberof periods of future forecasted demands in which the inventory position is to be increased at ttie begin- 
ning of period t. if below 

Algorithm 

Step 1 : Conipute bt = St -i- S|^i Snt- (If nt is specified as a fractional value, bt equals: 
bi = St + S»^i+...+ SLnti + (nt - LnJ) ^jti^ 
Step 2: Project r and P' lina Let: 

lb = inventory position (inventory level plus outstanding orders) before ordering at beginning of period 1 . 
Pt = production volLvne ordered at beginning of period t. 

Set Pi = bi - 1©; project recursively for t ° 1 T-1: 

It^i=max(bt.lt) + Pt-S, 
Pt^i = max(bh.i-lt^i ;0) 

Step 3: Evaluation of various service and cost me^ures. 

a) ag., expected average inventory level, 

b) probat)ility of stock-out. 

c) f 01 rate or percentage of demarxJs satisfied from stocK 

d) rumber of settps, 

e) average t)acklog sizes. 

MI.1 .2 MIN-MAX Policies Based on Optimization of Aggregate Cost Measures 
Ot)jective 

In this nfKxJel, a policy is computed which minimizes the expected value of the aggregate of all relevant cost com- 
ponents, i.e. 1) setup costs; 2) inventory carrying costs: and 3) backfogging costs. The rnodeH is appropriate in s^ngs 
where stock-outs are fully backfogged and where the inventory carrying and bacMogging costs are proportfonal with tf>e 
inventory l^els and backfog sizes. 

Additfonal inputs: 

HoMing cost rates per item per period (h* line) 
Backfogging cost rate per itenr^ per period (p* line) 
N^rable production cost rate per item per period (c* line) 

Algorithm 

^ep 1: Ljoad S* (Sales), <f (Standard deviation). L* (Lead times), x* (Standard deviations of lead times), K* (setup 
costs), h* (HoUing cost rates), p' (bacMogging cost rates), c* (variable productfon cost rates); 
Step 2: Frt appropriate demand distribution to S*. a' lines. 
Fit appropriate lead time distributions to V and V lines. 

Step 3: Solve for time-phased optimal (s.Q) policy. Such a polfoy has for each period t ^ i T. two critical levels St 

and Ox such that whenever beginning inventory position lt<St an order is placed for (SffQt - It) units. Parameters (St, 

Qt) are computed from the fblkmng recursion. 

Let: 

Vt(0 = expected nvnimum costs in periods 1 1+1 T given that perfod t starts with an inventory position of I 

units. 
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Gtty) = expected (inventory carrying and baddogging) costs associated with period t (This function uses the 
lead time and demand distrSxitions computed in Step 2 as well as the h' and p* lines.) 
Dt = demand in period t 

s Solve: 



Note: the user is provided with the option taspedfy ranges for the production quantities x^. x^^^ .... ^j- These ranges 
may reflect capacity limits per item, or flexibility limits in view of prior detemiined P* and V lines. The ranges will be 
used to restrict the choice of X . 
Output: 
IS For all t= 1....,T; 

Xt*(Q = optimal order quantity at the beginning of period t when inventory position s I. 

Step 4: Create 1* and P* lines. 

20 1^ is known; set Pi = production lot initiated in period 1 equal to X*^ (I). Then project recursively for t = 1 T 

lt*i = lt + x^(IO-S, 

25 Step 5: Evaluation of various cost and service measures, as in Step 2 of model Ml .1 . 
MI.1 .3 Periodic Review Modete Under Service Level 
Constraints 

30 

Objective 

In this category of models the inventory policy minimizes expected settp and holding costs subject to user speci- 
fied sennce level constraints. The user may choose between the two types of conventional service measures. 

35 

Type 1 Service Constraints: 

Maximum permitted probability of a stock-out during lead-time following potential order at t>eginning of a given 
period. L^: 

40 op maximum pemnitted likelihood of stock-out during lead-time folkywing potential order at beginning of period 

t 

Type 2 Service Constraints: 

Minimum acceptat>le fill rate during lead time following a potential order at beginning of period. Rtl rate is defined 
45 as the percentage of demand satisfied from stock. 
Let: 

Pp minimum acceptable fill rate during lead time following a potential order at beginning of period t. 

50 The model is based on the same assumptions as Ml. 1 except that stock-out frequencies are controlled via servk^e 
level constraints (of Type 1 or Type 2) as opposed to explk;it stock-out or bacMogging costs. 

Additional Inputs 

55 hoMing cost rates per item per period (h* line) 

maximum permitted stock-out prot>at>ilities per item per perkxl (a' line), or minimum acceptable fill rates per item 
per period (p' line) 
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Algorithm 

Step 1 : Ijoad S' (Sales), a* (standard delations), L* (lead-times), K* (setup costs), h* (holding cost rates), c' (variable 

production cost rates), a (service level type 1) or p* {sennce level type 2). (Lead-times are specified eittier as corv 

stants a via ranges with associated likelihood for each value in the ranga) 

Step 2: Frt appropriate demarxJ distribution to S\ a* fines. Determine lead time demand distrbutions. 

LBt: 

Wx = lead time demarxi for order placed at t)eginning of period t If lead time demarxl distrOsutlon is chosen to 
be Normal (for exanrple). then set its mean and variance as follows: 



Step 3: Compute rnnimun inventory positions after ordering S| . via Reorder Point Algorithm, below: 

Step 4: Solve for time-phased optimal (s.Q) policy. 

Let 

V, (I) = expected minimum costs in periods t, M T given that period t starts with an inventory position of I 

units. 

Gfy) = expected inventory carrying and backlogging costs associated with period t 
Dt - demand in period t 

Solve: 

t = 1, . . . ,T; all I 



Output: 

forallt = 1....,T; 

x*| (I) = optimal order quantity at the beginning of period t. when inventory position » I. 

Note: the user is provided with the option to specify ranges for the production quantities X), x^.i.....Xj. These ranges 
may rellect capacity limits per item, or f lexit>itity linrnts in view of prior determined P' and r lines. The ranges will be 
used to restrict the choice of X in (2). 
Step 4: Create I* and P lines. 

1^ is krKMvn; set Pj = production lot initiated in period 1 equal to x*t (I). Then project recursively forts 1 T 

lt^i = lt + ^*t(lt)-S, 
= (h+i) 

Step 5: Evaluation of various cost and service measures, as in Step 2 of model M1.1. 
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Ml^ Mutti-ltem Capacitated Pericxjic Re^ew Models with Service Level Constraints 
Objective 

Th^ category of models plans simultaneously for a complete fanvty of items incorporating various joint capacity 
constraints. The model plans production quantities on the basis of estimated mean demands; however, minimum inven- 
tory levels are specified to satisfy user specified service constraints (of Type 1 or Type 2, see MI.1 .3. atx>ve). The P* and 
r line are In this case determined t3y the solution of an LP-model. The user specifies whether minimum inventory levels 
are to be d^ermined on the baste of Type 1 or Type 2 constraint& In addition, the user chooses among a number of 
possible objective functions (performance measures) to select among feasbte plans. 

LP formulation 

Model: 

LP formulation for I products (or product group) K resources (Key Gonponent arxl/or Lines) sets and T periods 
Input 

Sh = Demand for product i at period t 

Sit = Minimum amount of product i at the end of period t 

Ijo = Initial Inventory of product i at the beginning of the planning horizon 

ami = ^ite ^ resource m. among resources in set S^. required per unit production/repair of product I 

Crnt - Units of resource m which becomes available at period t (In case resource m Is a key corrponent, c„,o the 

amount it available at the beginning of the horizon under consideration.) 

Decision Variables: 

P{t = Units of product i to procAx;e In period t 

Xmjt = Units of product i to produce in period t using resource m in 

Ijt = Inventory of product I at the end of period t LP (A) Optinuze: 

CV1, 0V2, 0V3 or 0V4 specified below: 

subject to 

Iit-i+Pit-Sit=Iit i 1,2,..-, I and t = 1,2,. ..,T (1) 

in sk3C«it*^*it: f or k = 1 , 2 , . . . , K, i=l,2, . . . ,1 and 

t » 1,2, . . . ,T (2) 

E-o « t^i a^x^,<«C,.o to tC». for each key component m and 

t « 1,2. .,T (2.1) 

j:ia^x^t<=Cnit each line resource m and 

t - 1,2, . . .,T (2.2) 

I^^iSit for i=l,2, ... ,1 and t = 1,2, . . . ,T (3) 

x^^aO for m in 5,^, k=l , 2 , . . . , K, i=l , 2 , . . . , I and 

t = 1,2, ... ,T (4) 



Constraints: 

calculate the inventory levels. 
(2.1) and (2.2) ensure that consmiption does not exceed resource availability, 
ensure inventory is no less than pre-spedfied levels and ensure that production/irepair is nonnfiegative. 
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Output: 

FeasilMlity of LP 

5 If yes. a production plan : Pjt for i = 1.2.....I and t = 1,2 T the COTesponding inventory levels : 1^ for i = 1.2....,l and 

t » 1 .2 T and remaining resources : slacks in (2.1) and (2.2). 

If no, display sources of infaasibility : surpluses in (2.1) and (2.2). 

0V1 : Maximze maximum slack In resource constraints (2.1) and (2.2) 
10 0V2: (Balance Workload). 
mini:[amiWCmt] 

0V3: Minimize variable production and holding costs 
mjn2:[CHPit + hftliJ 

0V4: Minimize maximum inventory in weeks 
75 minmaxH[li/Sit] 

Algorithm 

Step 1 : Load S* (sales). & (standard deviations), L (lead times), h* (holding cost rates), C (variable production cost 
20 rates), t* (standard deviations of lead times); resource utilization matrix [a„,J capacity levels [CmJ. 
Step 2: Determine lead time distrbutions LD^i as in Step 2 of Ml.1.3. 

Step 3: Compute minimum inventory positions after ordering Si ,"\&t via Reorder Point Algorithm. 

Step 4: Solve above LP. 

Step 5: kientical to Step 5 of model Mil .1 . 

25 

M 11. Inventory Models for Lumpy Demand 

Apply to lumpy demand. The lumpiness of demand is measured as proposed herein. 
30 M 3.1 Maximum Demand during Period *n' Policy 
Ot)jective 

This policy is suitat)le for tow cost slow moving items with lumpy demand. 

35 

Inputs 

S* line, cover period n. 

40 Outputs 

MAX level, inventory target. 
Frames using these models include 
PSI Planning Frame 160 (CF8) 
45 VMR Frame 250 (CF19 and CF20) 

Algorithm 

Step 1. Use method 1 to categorize lumpy demand 
50 Step 2. Detemnine *n'; a worst case scenario woukJ be to set 'n' as ttie replenishment lead-time. 

Step 3. Determine the maximum demand duing period 'n' and set it as the inventory target, MAX. 

Step 4. Compute V line: 

Iji-i+Xji^i = Ijtforj = 1,2,...,J and t = 1,2,...T 

55 M 3.2 Expected Deficit MIN-MAX 

Objective 

This policy is suitable in cases where there are fairly expensive items that have liffnpy demand. 
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Inputs 
S* line 

5 Outputs 

Max ley^el, inventory target 
Rame using the nxxjel irK^es 
PSI Planning Frame 160 

10 

Algorithm 

Step 1. Use method 2 to categorize lumpy demand 

Step 2. Define expected deficit due to lunrpiness as average annount that the quantity on hand is likely to fall before 
15 a replenishment order is placed. 

Step 3. Approximate the expected deficit (average period sales) as one4^ of the t>eginnlng and mfing quantity 
on hand t>etween quantity-on-harvi record updates. 

Step 4. Set ROP as safety stock plus demand during the lead-time and expected def k;rt. 
Step 5. Set the MAX level as the ROP quantity plus the order quantity less the expected defk;it 
20 Step 6. When the inventory level reaches the reorder point the diff^ence between the targeted quantity MAX and 
the quantityK)n-hand is ordered. 
Compute the t' line: 

= Ijt for j = 1 ,2 J and t = 1 ^,...T 



MODEL 


WHERE USED 


Inventory models for independent 
items with non- lumpy demand: 

• User specified base-stock 
policies 

• Min-max policies based on 
optimization of aggregate 
cost measures 

• Periodic review models 
under service level 
constraints 


PSI Planning 
VMR 


Inventory models for multi-item with 
non- lumpy demand: 

• Capacitated periodic review 

model with service level 

constraints 


PSI Planning 


Inventory models for lumpy demand 

• Maximum demand during 
period 'n' policy 

• Expected deficit min-max 
policy 


PSI Pleuming 



45 

Table 11 
Usage of FGIM Models 



50 

Models specific to repair environment 
Determining CSI levels 

55 

Objective 

To detemtir^e CSI level for each module typa 
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Input 

repair shop repair tinne estimates 

consolidated requirenients for equipnrtent for the previous periods 

5 

Output 

CSI levels for each repairatile item type 
10 Algorithm step 

For each repairaksle item, set CSI level to CSImin. calcUate the corresponding performance measures^ Based on 
values of the performance measures and the esti ma ted consolidated requirements, change tfie CSI level arxl repeat. 

Peribnmance measures that can be considered fbr determining the CSI level for each repairable item are the total 
15 cost of repair (setup cost -i- repair cost), and the fill rate (service level) at the repair shop. 

CSI level fbr each repairat)le item nust t>e greater ttian or equal to the value of CSI^iin, which is sinrpty the sum of 
the requirements during repair time and a safety stock. CSImin ^ E[requirements over all equipment locations during 
repair time of one unit] + safety stock where safety stock is a user defined parameter, based on p^ requirements. 

20 Determining aggregate repair resource requirenr^ents 

Objective 

This process includes the objectives: (i). to estimate numk>er of consolidated requirements for equipment triggering 
25 repair at the repair shop; (iO- given (i), to estimate number of repairable items requiring repair at the repair shop; and 
(ni). given (ii), to estimate aggregate repair requirements at the repair shop 

Input 

30 CSI levels 

consolidation policy target level 

Types and numbers of repairat)le items in each equipment 

BOM for each repairable item (to go to the component level) 

Final estimations of consolidated requirements fbr the equipment 
35 Final estimated repairable item requirements corresponding to the consolidated requirements for equipment 

Repair data for each repairable item (operation sequence and repair time estimates for each operation) 

Output 

40 Aggregate repair requrements at the repair shop 
Algorithrnc steps 

Estimate number of consolidated requirements fbr equipment triggering repair at the repair shop 
45 Estimate namber of repairable items requiring repair at the repair shop 
Estinrate aggregate repair requirements at the repair shop 
Generation of a feasible aggregate repair plan 

Objective 

50 

To generate an aggregate repair plan based on aggregate repair requrements, and repair constraints (resource 
capacities and key component availat>ility). 

Input 

55 

Aggregate repair requiremerrts 

Available resource capacities and degree of f lexft>ility to change resource capacities 

Key component availability (projected inventory positions, supplier and lead time information, inventory replenish- 
ment policy) 
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BOM for each repairable Hem family (to go to the component level) 
Output 

s Aggregate repair plan for the repair ehop that is feasble with respect to the repair constraints (capacity and 
component avaOabilit^ 

Algorithmic Steps: 

10 Check if aggregate repair requirements are feasft)le with respect to capacity constraints of the resources 

tf not change capacity levels of flexible resources. If still infeasble* point out infeasibilrty and go t>ack and move aggre- 
gate repair requirements forward or backward in time 

Determine key component requirements and time of requirement from aggregate repair requirements 
Check if aggregate repair requirements are feasible with respect to key corhponerrt availability corrstraints 
IS H not point out infeas3>ility in terms of component availability. Change key component availability (if it can be changed) 
equipment based on the purchasing poltdes for the components. If still infeasible. go back and move agsp'egate repair 
requirements forward or backward in time until a feasft)le repair plan is generated 

Aggregate Production Planning (APP) 162 

20 

The Aggregation Production Module 162 focuses on its PSI Frame 160 application. The tblkiwing two capacity 
checking models are identified and devetoped to support the Model Engine 20 requirements in the PSI Frame 160. 

Objective and Scope 

25 

Objective: Facilitate the master production scheduling process 
Scope: Rnished goods production in some aggregate view. 

Features: Rough-cut capacity checking for finished goods; Major components (feeder plants) represented in con- 
straints; and Ability to identify violated constraints. 

30 

Capacity Checking Models 

In the Capacity Checking models, the problem of checking wfiether tfiere is enough resources to satisfy require- 
ments is formulated as Linear Programming Problems. These models are applicable to both the manufacturing and 
35 repairing environment in the PSI frame. The capacity checking models are presented in manufacturing terms these 
models also apply to the repair environment and are used in the context of the Requirement-Supply Reoorx:iliation 
frame to assess the feasibility of a repair plan. 

Sales and safety stock sanity check 

40 

Objective 

Check whether there is a feasible production plan to satisfy given sales and safety stock requirements. 
45 Input 

I = The number of products to be considered. 

K = The number of resources (production lines and key corrponents) sets. 

Sk = The set of resources. 
50 T = The planning horizon. 

Sjt = Demand for product I at perkxl t. 

ISSjt = Safety stock of product I at the end of period t 

Ijo = Initial inventory of product I at the beginrdng of the planning horizon. 

a^nj = Units of resource m, among resources in set Sk, required per unit production of product I. 
55 Cmt = Units of rescues m wfiich t>ecomes available at period i (In case resource m is a key component Cmo is the 

amount of it availat>le at ihe beginning of the horizon under consideration.) 
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Output 

Feasibility of LP 

5 H yes, 

a production plan: 

Pi,forl=1^ Iandt = 1^,...J 

the coresponding inventory levels: 

litfor i = 1,2 1 and t = 1.2.... J 

10 and remaining resources (slacks in constraints (3) and (4)): 

" 2:s-otoi<W-^tot2^iamP^for each key conponemni and t= 1,2 T and Cmt- 2^ iamp(mH*>r each production line 

mandt = 1,2 T. 

Iff no, display sources of infeas3>ility (surpluses in constraint (3) and (4)): 

tot2^iamP«rn»-2:8-oioi<W for each key conponertm^ T and Lja^H-Cnitfof each Productton line 

15 mandt = 1.2,...,T. 

Linear Programniing F6rmulatk>n 

Decision Variat)les: 

20 

Pit= Unitsof product I to produce at period t 

Xrnit = Units off product I to produce at period t using resource m in set S^, 
d-rt ^Demand for product I during the period t 
\n = Inventory off product I at the end off period t 

26 

Objective functions: 

Minimize maximum production line utilization (smooth production line utilization): 
Minimize z 

30 subject to L 1 amiXmi/Cmt <= z foT each line resource m and t = 1 ,2,...,T 

Minirroze maximum inventory level: 

Minimize z subject to Ijt <= zfor i = 1,2 1 and t = 1,2 T. 

Minimize total inventory level: 

Mininruze If lit 
35 Minimize total inventory cost 

Minimize EjEt (hit Ih*+ Pit Irt) 

subject to lit = lit*- lit', lit*>= 0 and lit" >c=Ofor I = 1,2 1 and t = 1,2 T 

where hit = cost per unit holding and 

40 Pit = cost per unit backk)g off product I at the end of period t 

Constraints 

Inventory t>alance formUa 

45 

iH-i+Prt-diplit for i = 1 .2 1 and t = 1,2 T. 

Resource allocation 

J^minSkXinit=Pitforfc=1.2,...,Kandt=1,2 T. 

Key comporient availatMlrty 
50 E8=otot2^i amP^te<= 2^to tCms for each key componertmandt=1A^^^ 
Prochjction line capacity 

£ I a^pc„,it<=c^ for each production line m and t = 1 ,2 T. 

Safety stock requirement 

lH>=ISSitfor i= 1,2.....landt= 1.2 T. 

55 Kk>n-negative resource allocation 

Xnrit>=0 tor m in Sk, k= 1,2,..., K, i = 1,2 1 and t = 1,2,...,T 

Capacity Checking Model 

CCM1 : User selected objective function subject to the atxve constraints. 
Frames using this model include RSI planning (CF13), VMR. (CF 20) 
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This LP formulation, with minor changes, is also applicable to a repair environment, where reparat)le items corre- 
spond to products, repair requrements for reparat>le items con'espond to demands for products, and broken repaFat)le 
items awaiting repair at the repair shop oorresporKl to key components. 

For the repair environment, key component avaitatMTity constraint (the fourth constraint) should be nxxiified as tn 
5 the following to represent broken reparak3le item availatxlity at the repair shop : 
4) Broken reparable item availat>9ity: 

2^ tot 2^ m^^is<=^ tot Ci8*>f each repairable itemiandt = 1.2 T. 

Objective functions and the other constraints in a repair environment will be similar to those of a production envi- 
ronment, which are given abova The LP nxxJel for the repair environment will either produce a capacity fea&S>le aggre- 
10 gate repair plan that satisfies the repair requrem&tts generated by reparable item failures or display sources of 
infeasibility. 

Production requirement feasibility check 
15 Objective 

Check whether a given production plan is feasible with respect to aggregate production capacity and key corrpo- 
nent availabifity. 

20 Input 

I = The number of products to be considered. 

K = The number off resources (production lines and key components) sete. 
S|( The set of resources. 
25 T = The planning horizon. 

PjP Units of product i to produce at period! 

ami = ^ resource m. among resources in set requred per unit production of product i. 
Cnrt = LJnits of resource m vvhk:h beconies available at period t. (In case resource m 
amount of it available at the beginning of the horizon under consideration.) 

30 

Output 

Feasft)ility of LP 

35 If yes, display remaining resources (slacks in constraints (3) and (4)): 

2^tot<W-2^tot^iamP«mBtof ©acf^l^yco'T^ TandCnrt-J^iampCmitforeachproductton line 

mandt=1Z...,T. 

If no, display sources of infeasitMlity (surpluses in constraint (3) and (4)): 

5^ toiJ^iamP^fe-^totCms for each key component mandt= 1,2 T and 2: lamPCmit-Cmt^w each production fine 

40 marxJt=1,2 T 

Linear Progranming Formulation . 

Decision Variables 

45 

Xnfit Linits of product I to produce at period t using resource m in set S|(. 
Capacity Checking Model 
50 CCM2 : Objective function 1) subject to constraints 2). 3), 4) and 6). 
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MODEL 


WHERE USED 


Capacity checking models: 

Sales and safety stock sanity check 

Production requirement feasibility 
check 


PSI Planning 
VMR 



10 Table 12 

Usage of APP Models 



75 

Vendor Managed Replenishment CVMR) 252 
Overview 

20 This section describes the specifications of the various models used in the VMR modules. The description is 
divided into three main categories: (1) Inventory Requirements Setting Models, (2) Strategic Models, and (3) Opera- 
tional Models. The notation for these models is introduced as necessary throughout this section. 

The models developed in this section are t>ased on prior resuHs in the professional literature as well as from other 
sources. 

25 

Scope and objective 

Objective: Analyze contractual agreements with customs; and Decide on wtiat to ship, in what quantities and 
when. 

30 Scope: Selected products for selected customers. 
Features: 

Evaluate policy parameters such as bounds on customer inventories, target service level and delivery frequencies. Sta- 
tistical forecast of retailers' sales (i.e. forecast of sales of PCEC's customers to their customers). Determine shipment 
requirements and delivery schedules. 
35 Inventory Positioning: The Multi-Item. Two Echelon Model 

Overview 

This section presents two models; the first nrxxiel descrit)es an algorithm for the calculation of required echelon 
40 inventories. (Echelon inventory = inventory in transit from the plant to the DC + inventory on hand at the DC + irrventory 
in transit from the DC to the stores + inventory on hand at the stores.) The second nradel estimates the expected level 
of service provided at a certain D.C. given a delivery quantity. Two important parameters used in both models are the 
expected value and standard deviation of the lead-time demand. These models compute the stock-out probat)ility of 
today's delivery on the day of its anrival to the storesw This is based on the approxirnati^ 
45 prior research on the Multi-Item. Two-Echeton productiori/inventory systems Setting Inventory Requirement: Model (R) 

Objective 

This module corrputes the required echelon inventory levels (R* line) at the beginning cf each review period over 
so the whole planning horizon. Clearly, these requirements depend on the delivery frequency used (the requirements 
increase as the delivery becomes less frec^ent). Thus, the required inventory levels (R* line) are calculated separately 
for each one of the pre-spedf led delivery frequencies. 

Input 

55 

Network structure. 

DemarxJ forecast (means, standard deviations and cfispersfon factor). 
Required servk^ levels (in terms of stock-out probak>ility). 
Set of possible delivery frequencies. 
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Lead-times from each ptant to e^ery DC it replenishes, and the average lead-times from every DC to the stores it 
suppGes. 

Planning horizon specifications 

5 Output 

Required inventory lines (R* lines). 

Notation 

10 

to - beginning period of tfie planning horizon (assuming that ^today* is the beginning of period number 1). 
T - the lengtti of the planning horizon. 

^^fiSi - required inventory level, of product j at DC I, at the beginning of period t when delivery frequency f is 
applied. 

15 as - required service level for product j at DC I. 

\i\ ' mean demand lor product] at DC I durirtg period t 

o^ij - standard deviation of the demand lor product j at DC I during period t 

b\ - demand cfispersion rate for product j at DC I. The dispersion rate is defined as follcws: 

" zmatozesti) 

and is assumed to be constant over time, stores (Q denotesthesetof stores replenished by DC I. Note that we do 
25 not require the data o^^r which represents standard deviation of demands at individual stores. The parameters b\{s 
can be calculated (or even roughly estimated) by an obsen/ation of a set of historical stores' data. 
Ljj - Lead-time from the plant that produces product j to DC I. 
X|- Average lead-time from DC L to its stores, for product j. 

Q - Set of 'quarters* into which the planning horizon is split Each quarter is a continuous time interval consisting of 
30 one or more periods. 

Q^. iQ^! - Quarter number q and the number of periods in it (note that ). 

F - The set of all possible delivery frequencies. Each delivery frequency f is specified as the rrunimal number of peri- 
ods between two consecutive delivery periods. The values f must be integral (for non-integral values, redefine the 
base period, e.g. half a week instead of a weel^. 
^ I^V*^)' ^|(nri) - The mean and starxiard deviation of the demand for product j at all stores supplied by DC I, ever 
periods t until t-i4HjH-Kn(ni^ is a paranrieter of these functions). The t the expected time at 

which a delivery shipped from the plant at period t-nn (next possfole delivery time), arrives to the stores. 

Algorithm Steps 

40 

For all product-DC couples (i,D 
For all frequencies f in F 
time :=0 

For an 'quarters* q in Q 
45 Fbrallperiodst=1 to)Q^ 
time := time + 1 

// compute the time to next feasible delivery period, 
t_del.// 

t_del:=f-[(t + f-1)modf] 
50 timeJo_DC := t_del + Ljj 

timeJo_slores := time_to_DC + ly 
compute the values 
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(R.2) 

(Ijf (t^de2)= V^ij 

and 



10 

(R.3) 



75 \ X-ciiM X^tiam^Lif^l^dml 



for a part of a period use the following interpolation method: LetXbetheperiodnunt>erandletO<a<1 bethefractk^ 
of that period. Then, 
20 (R.4)mean = a 

(R.5) std = 



25 



Use (R.5) if the demand in this part of the period is assumed to be independent of the demand during the rest of the 
period. Another way to calculate the standard deviatfon can be. for instarx^e. 



30 



std=a'Oij 



The inventory requlrenDent for period time is new computed via 

35 (R.6) 

Rf^ {i.j) ( tjiel ) **-M 1 -o^p d -i^f* ( t_del ) 



40 End For (t) 
End For (q) 
EndF6r(f) 
End For (ij) 

Estimate Stock-out Probability for a Given Replenishment 
45 Quantity: Model (0R1): 

Objective 

For a given replenishment quantity of product j. delivered from plant p(j) to DC I. this model estimates the expected 
50 projected stock-out probatMlity. The stock-out probability is defined as the probability of shortage in at least one of the 
stores replenished by the DC The word ''projected" refers to lead-time periods later, when goods are expected to reach 
the storeSw 

Notation 

55 

In addition to the notation defined up to this point, we define: 

DELfV - delivery siza 
date -date of delivery. 
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arr - (expected) arrival date of goods to stores 

Xjj^*° - the echelon inventory level of product j in DC I. at (period) tinrie date. 
Algorithm Steps 

Use fornujla (R.2). with t_del=1 , to calculate the expected demand over the lead-time, 



dMtB 



10 



(1). Similarly calculate the standard deviation of this demand. 



d 



date 



15 



(1). via formula (R.3) (again, ty setting t_del=1). 

The projected stock-out probat)ility can be approximated t>y: 



(OR.l) 



20 



Aff'^^^i?KLJV-^g''^(l) 



25 



30 



In certain situations the user may be interested in krrawing the projected service levels for periods further than an*. Such 
Interest may arise when no deliveries are planned for subsequent (nunrt>er oQ period(s). To equate the projected 
stock-out probat)ilfty at period arr4k, when no deliveries are to be made during the following k periods (i.e. date^-l, .... 
dat&fk), use the formula: 

(OR. 2) 



35 



date s 



d^"(i+ic) 



strategic Model: VMR Contract Setup ® 
40 Objective 

This module consists of a set of nnodels tailaed to support replenishnrtent planning by inte^ting: (1) service level 
requirements; (2) limits on customers* inverrtory investments; (3) transportation costs; and (4) delivery frequerKy. 

45 Input 

Bek>w is the ir^ which is comnfK>n to all of the models described in this particular discussion: 
Network Structure, 
Demand Forecast 

50 Lead-times from each Plartt to each DC and (an average) from each DC to its Stores, 

Planning Horizon Specificatk)n8 

Current Inventory Positions, 

Transportation Cost Structure and Trucks Volumes, 

Products' Vblumes (for Transportation Cost Cakxilations), 
55 Computing TTte Optimal Delivery Rrequendes: Model (CI) 

Objective 

This model computes delivery frec^endes from each plant to the DC it replenishes such as to minimize total trans- 
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portatkMi costs. Tbe delivery frequencies are set such that given requirements on service levels are satisfied and such 
that constraints on average inventories are not violated. 

Input: 

5 

Inventory Requirements (R* Line, see Mod^ R). 

Set of Possitsle Delivery Frequencies, 

Required Service Levels (in Terms of Stock-out ProbatMlities), 

Limits on Maximal Inventory Investments (in terms of Weeks of Demand), 

10 

Output 

Delivery Requendes. 
Estimated Level of Servk^e, 
15 Estimated Transportation Costs, 
Estimated Inventory Levels, 

Notation 

20 We use the same notatkxi && in Model R (except for the notatk)n for delivery frequencies) plus tfie following: 

Indices 

i - DC index 
25 j - product (module) index 
p - plant index 
f • delivery frequertcy index 

s - index of line segnrtent of transportation cost functbn (the cost structure is approximated by a piece-wise lir>ear 
function) 
30 t- time index 

q - quarter index 0 

Sets 

35 I - s^ Of all DCs 

J - set of all products 
P - set of all plants 

F - set of possi>le delivery frequerxaes 
- all products soM to DC i. 
40 Jp - all products produced in plant p. 

Transponatfon cost parameters (for deliveries from plant p to DC i) 

voljp - total volume of a single truck 
45 c^- cost of full truck k)ad(FTL) 

fixp - fixed cost of less than full truck k>ad (LTL) 

'^•pfi • (right) end point of the s-th line segment (i e., [t^s^i , ip,s] ) of the LTL cost functfon. 
ratOip 8 - transportatkxi cost rate for volumes in segment s (i.e., in t)etween g.^ and x-^^^, for LTL shipments. 
V| - volume of product j (for cost cakniatfon purpose) - upper limit on the average number of weeks of inventory in 
so DC i in quarter q. 

Decision variables 

X^jj - echefon inventory of product j at DC I (including outstanding orders) in the beginning of period t. 
55 S'ij - delivery quantity of product j to DC I in period t 

- an indicator set to 1 if in quarter q a delivery frequency f is followed for the reptenisfvnent of DC I by plant p. 
Otherwise it is set to zera 

NFT'ip - number of full^truck-foad sent to DC 1 from plant p during period t. 

LTL^{p - volume of LTL (zero if none) shipment sent to DC I from plant p during period t. 
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Y'jp^ - total volume of LTL shipment that falte into line segment (cost rate category) number s. Note that . 
7}-^jQ - an indicator set to 1 if the LTL shipment size is larger than Tjp^^; l.a, segment s is partially or entirety coh- 
ered. Note that Z^ip^s ^ always less or equal to Z*^^^ . 

5 Algorithm Steps 

The fbllawing Mixed-Integer Linear Programming problem is solved: 
Problem (C1): 



10 



ST. 

75 Irtitialize inventory positions: 
(C1.1) 



Xg ^=Xq ^ i.j 



20 System dynamics: (expected) beginning DC echelon inventory = (expected) beginning inventory of last period + deliv- 
ery quantity to the DC during the last period - expected demand in the last period: 
(C1^) 

X^^z^X^'-^+Si'-^-ji,/^ ij,t>1 

25 

Beginning (expected) inventory level needs to satisfy the requirement constraint, for the relevant frequerK^y level: 
(01. 3) 

UF 

Only one frec^ency is chosen for each triple (DC, product and quarter): 

35 

(CI. 4) 

40 

Average echelon inventory (across all products) should not exceed a given level. This level is given in terms of weeks 
of inventory, f^ote that we siMract one half since X is the beginnir^g inventory level (while we are interested in average 
over tfte period, i.a, X-|iy2): 

45 

(CI. 5) 



50 

Upper bound on the numt^r of full truck loads (FTL) : 



^•l^n-ffEE^VEE^^M^^ 
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(CI. 6) 



10 

Lower bound on the number of FTLs: 
(CI. 7) 

15 



-1 



20 

Deliveries not send by the FTLs are sent by LHj 
(CI. 8) 



25 



30 

Setting the transportation cost constraints (See 4.8.1): 
(CI. 9) 



35 



40 



(CI. 10) 



45 



(CI. 11) 



(CI. 12) 



2ip.s€{0,l) 



55 



Integrality constraints 



*ip»8^^ip»a*\ 

SO i,p,t,s 



i/P/ t,s 
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(CI. 14) 

i/P*q,f 

(CI. 15) 

NFTijj£,In tegers 



75 To estimate the operating parameters, descrft)ed above as part of the output of this model, use Model (04) (descnk>ed 
later). 

Corrputing Maximal Average Levels of Service: Model (02) Objective: GSven the delivery frequencies and limits on the 
average number of weeks of (echelon) inventories, this model calculates the maximal average service level that can be 
obtained. 

20 

Input 

Inventory Requirements (R* Line, see Model R) 
Delivery Frequencies 
25 Limits on Maximal Inventory Investments (in terms of Weeks off Demand) 

Output 

Estimated Level off Service 
30 Estimated Transportation Costs 
Estimated Inventory Levels 

Notation 

35 We the same notatk>n as In Model 01 plus the following: 

<^Sl - IfHojected* (i.e. lead^me" periods after period t) level of service for product j in DC I at period t 
T|p - a given set of perkxis in whwh replenishnient (from plant p to DO I) is pernrM 
W|j - values of objective coeffk;ients (see discusskm later) 

40 

Algorithm Steps: The folkTwing problem is of interest 
Problem (02): 

MAX ^y: ^i^^h 

S.T 

(02.1) (C1.1) 
50 (C2.2)(C1.2) 
(02.3) (01.5) 

Formula used to approxinrtate the "prcjected" level off servk^e (see Model (0R1): 
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(C2.4) 



\ oh J 



10 



No delivery can be made in periods that are not conpfiant whh the given delivery frequencies 



(C2.5) 



IS 



Sij=0 for all tfT^ 



20 Note that Problem (C2) is separable both in I and in q. In addition, in order to deal with the norvlinear constraint (C^.4) 
we approximate the Standard-Normal cumulative distribution function (0) k>y a piecfrwise linear function (with m seg- 
ments); for further details, see below. 

As in Model (C1), we define for the piece-wise linear function the parameters and variables (for further details, see 
below): 

25 

m - number of "segments" in the piece-wise linear function. 

- the s-th breakpoint of the piece-wise linear function (s=0 m); i.a the s-th segment is given by [e^.^ , ]. 

dg - the slope of the s-th segment of the piece-wise linear function (s=1 m). 

Z*| 8 - the binary variables associated with this transformation. 
30 Vj 8 - the continuous variable associated with this transformation. 

In the following problems we use Z^j g and with respect to 

T={x/j-(Lh)/ah. 



see below. 
Problem {CZf^ : 

40 



45 S.T. 

(C^M) (C1.1) only for the relevant value of i and teQq 
(C2\2) (C1.2) only for the relevant value of i and tcQq 
(C2'.3) (C1.5) (single constraint) 
See the discussion herein for details on (C2*.4)-(C2*.8): 

50 
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(C2'.4) 



70 



IS 



20 



30 



35 



40 



{C2' .5) 



(C2' .6) 



(C2' .8) 



j/t,S 



(C2'.7) 



s-1 



45 (C2*.9) (C2.5) only for the relevant value of I 
Remarks 

The weights Wjj should be set such that 

50 

55 . To determine the appropriate weights one should consider the relevant factors that need to be taken into account (e.g. 
priorities, demand volumes, etc.) 

In case that some products have lew service levels, the problem can be resolved with the addition of the following con- 
straint 
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(C2' .10) 



10 

where tpij are prespedfied lower bounds on the level of service. Another optron^which does not require the specification 
of(p|is 

{C2' .11) 

IS 

"Off j€J^ 

withn^l. 

2s Mininnizing Average DC Echelon Inventory Levels: Model (C3) 

Objective: Given the delivery frec^erKtes and required service levels, this nKXiel conrputes the minimat average 
number of weeks of inventories at each one of the DCs in every quarter. 

Input 

30 

Inventory Requirements (R* Line, see Model R) 
Delivery Requendes 

Required Service Levels (in Terns of Stock-out Probabilities) 

35 Output 

Estimated Level of Servk^e 
Estimated Transportation Costs 
Estimated Inventory Levels 

40 

hk>tation 

We use the same notation as in Model 02 plus the folkMving: 

45 pO) - the plant in wfiich product j is produced, 
q(t) - the quarter to whk:h period t bekxigs. 

R^ij*) - this is the inventory requirement as defnied for Model R. but without the sut>scr^ 1 It now refers to the given 
delivery frequency from plant p(j) to DC I in quarter q(t). 

AVG^j - the average echelon inventory level in terms of weeks of demand (for DC I in quarter q). 

50 

Algorithm Steps 

F=6r each DC I in I: 

55 Step 1: For each product j, j€ J' : 
Solve the follCNving prot)lem: 
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S.T. 

(C3.1) (C1 .1) (single constraint) 
(C3.2)(C15) 

Beginning inventories rm^ satisfy minimal requirements: 
(C3.3) 



End For® 
Step 2: For each q in Q 
Calculate the value 

(C3.4) 



End For (q) End For (I) 
Computation of Operating Parameters: Model (C4) 
Objective 

Given a delivery plan (i.e. the values S^^, this model computes the following operating values: (1) estimated inven 
tory le/els, (2) estimated levels of service, and (3) estimated transportation costs. 

Input 

Delivery Plan (8*5). 

Output 

Estimated Level of Service 
Estimated Transportation Costs 
Estimated Inventory Levels 

Notation 

P* - Set of all plants that replenish DC 1. 
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Algorithm Steps 

For each DC I in I: 

Step 1 : Evaluate the expected (echelon) inventory positions at the t)eginning of each period via the equations 
(C1.1), (C1.2) 

Step 2: For each quarter q in Q 

2.1 Evaluate the value AVG^j via (C3.4) 

2.2 Evaluate the expected levels of service 0 via (C2.4). 

2.3 Evaluate total transportation costs over the quarter (can be done by an external procedure) for each plant . 
End For (q) 

Check Compatibility of a Gven Set of Cor^traints: Model (C5) 
Objective 

This model checks whether a set of constrains (service levels, maximal echefon inventory levels and defivery fre- 
quences) is compatble or not. 

Input 

Inventory Requirements (R* Line, see Model R) 

Set of Possftsle Defivery RequerYcies 

Required Service Levels (in Terms of Stock-out Probabilities) 

Limits on Maximal Inventory Investments (in terms of Weeks of Demand) 

Output 

FeasitMlity (Yes or No) 
Algorithm Steps 

For each 1 in 1: 

Step 1 : For each plant pe P: 

Select the most frequent among the feasible delivery frequencies from plant p to DC I (this represent the less 
restrictive constraint). 

For this delivery frequency, evaluate the inventory requiren>ents R^Lj) by using Model R. 
Cak:ulate the values X*^ as in Model C4. 
End For (p) 

Step 2: For each q in Q 

Evaluate the value AVG^j via (C3.4) 

Check that 

is satisfied. If not STOPI the set of constraints is incompatibia 
End For (q) 
End For (1) 

Determine Productbn and Delivery Schedules: Model (C6) 
Objective 

This model suggests both production and delivery schedules which minimizes total transportation costs and (in- 
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plant) inventory hokfing costs. The plan Is determined under service level constraints and constraints on average inven- 
tories at ttie DC (echelon) levels. 

IfYXJt 

5 

Inventory Requirements (R* Line, see Model R) 

Set of PDssUe Defivery Frequencies 

Required Service Levels (in Terms of Stock-out ProbatMlities) 

Limits on Maximal Inventory Investments (in terms of Weeks of Demand) 

10 

Output 

Delivery Frequencies 
Estimated Le^ of Service 
15 Estimated Transportation Costs 
Estimated Inventory Levels 
Estimated In-Plant Inventory Costs 
Proposed Production Plan 

20 Notation 

We use the same notation dei\ned ip to this point plus the folkiwing: 
Parameters 

25 

hj - holding cost, lor unit of product j (in plant pQ")), per period. 

inv^ j - inventory of product j in plant (pQ)) at the t>eginning of the planning horizon. 

M - iMg" number (see (C6.5)). 

30 Sets 

IQ) - set of all DCs that carry product j. 

Decision variables 

55 

PROD^j - production batch size of product j in period t 

INV*| - inventory of product j in plant p(D at the beginning of period t 

Algorithm Steps 

40 

The folkwving Mixed-Integer Linear Programming problem is solved: 
Problem (C6): 

45 E E hp ^l>fiX,^' ^ip.l+E "^^^/P.i^' ^iP-sl* 

QbO t«Cg t»P I 8 \ 

SO S.T 

(C6.1)(C1.1) 
(C6.2)(C1.2) 

Initialize levels of in-plant inventories: 

55 
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(C6.3) 



* 

10 

Inventory dynamics 

beginning Inventory = last period k>eginning inventory + production quantity in the last period - goods delivered during 
the last period: 

IS (C6.4) 



id 



25 Delivery can be made only if period t is consistent with the chosen delivery frequency: 
(C6.5) 



(C6.6)(C1.4) 
See (CI .3): 

(CS.7) 



45 

{C6.8)(C1.5) 
50 (C6.9)(C1.6) 

(C6.10)(C1.7) 

(C6.11) (CI .8) 

(C6.12)(C1.9) 

(C6.13)(C1.10) 
55 (C6.14)(C1.11) 

{C6.15)(C1.12) 

{C6.16)(C1.14) 

(C6.17)(C1.15) 

Options for Production Capacity Constraints: 
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(C6.18) 

PRODjUprod^ 



10 

. This set of constraints represents indnndual 



This set of constraints is relevant when the different products, manufactured in a certain plant p, share critical capacity 
resources. Although (C6.19) represent a single constraint for each plant (in a give period t), more constraints can t>e 
25 easily added. Note that tx>th in (C6.18) and in (C6.19) lower tx>unds can t>e introduced. 

Limits on Storage Capacity 

Similarly to (C6.18) and (C6.19), analogous sets of constraints can be constructed in order to express, for each 
30 plant: (1) limits on individual storage volumes, arxJ (2) upper limits on total volume (value) of storage, respectively. 

Operational Models (OP): 

Overview 

35 

In this section we descn'be a family of models, analogous to Models (01 )-(C3). The models are built to assist pro- 
duction and delivery planning for the short-term horizon. The maior characteristics of these models are: 
Rolling horizon planning: production and delivery plans are made frequently (even before the end of previous planning 
horizons), thus taldr^g into advantage ifxiated information atxHit demands and production capacities. 
40 High level of details: capacity constraints are more detailed so that the resulting plan will txith be feasisle and smoothly 
translated into productfon orders. 

Rexbility in setting non-delivery periods: the user is allowed to specify periods in which delivery cannot be made. This 
replaces the requirement for follcwing a certain delivery frequency. For instance, even if there is a certain gudeline on 
delivery frequency, it can be relaxed at any (arbitrarily chosen) period. This reflects in added flexibility, which is espe- 
45 dally important in cases of unexpected, high levels of demarvte (i.e. when deliveries must be made quickly). 

The nurTt>er of constraints (per period) is larger in these nxxiels, however, the planning horizon is usually much 
shorter than that of the strategic model. In adcfition, since we do not need to select certain delivery frequencies there is 
no need to incorporate the integer variables f^pf. This results in a signif icantty faster solution time. 

50 Joint Production-Delivery Plan: Model (OP1) 

Description 

This model minimizes the total transportation arxJ (implant) inventory holding costs (see Model 06 for more details). 

55 

Notation 

The notation here is similar to that of Model 06 with the addition of the following: 
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Parameters 

req'i - requiremerrt for echelon inventory level of product j at DC I in period t in order to maintain a certain level of 
'projected'' level of service (see Model 0R1 for further clarification). This minimal level depends on the delivery 
5 schedule, see Model R for explanation on how to calculate these values (very similar to the calculation of the values 

- the same as xf but now without the quarter index, 

10 

cap*p(k) - the availability of resource k in plant p, in period t 

X^j(k) - the anx)unt of resource k required for a production of unit of product j in period t 
stora93^p04 ' maximal total volume/value (etc.) of inventory remaining at the end of period t in plant p. 
IS p'|(k) - the votumeAaf ue (etc.) of unit of product j in period t 

setup^j - setup cost to initiate a production batch of product j in period t 

Sets 

20 NoDeljp - set of periods in which no delivery is allowed from plant p to DC I. 

Decision variat)les 

PROD*j - productkm batch size of product j in period i 
2s IN\A - inventory of product j in plant pQ) at the beginning of period t 

SEPj - an integer variable indicating whether a setup is required in period t for product j. 

Algorithm Steps 

30 The folkwving Mixed-Integer Linear Programming problem is solved: 
(0P1): 

^-^^ E \=iT.'^^iv^^^^^ip^iP. 1 ^^ip.s^L si ^E ^iE 

ter peP[ 8 \ JcJ c 

35 

S.T 

(0P1.1)(C1.1) 
(0P1.2)(C1.2) 
40 (OP1.3)(C6.3) 
(OP1.4)(C6.4) 

Deliveries can t>e set to zero at any period the user chooses: 
(0P1.5) 

45 

^i^=0 i,j,teNoDeli^p^jy 



50 Echeton inventory levels must exceed certain levels: 



55 
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(0P1.6) 



(OP1.7)(C1.5) 

(OP1.8)(C1.6) 

(OP1.9)(C1.7) 

(OP1.10)(C1.8) 
75 (0P1.11)(C1.9) 

(OP1.12)(C1.10) 

(0P1.13)(C1.11) 

{OP1.14)(C1.12) 

(OP1.15)(C1.14) 
20 (OP1.16)(C1.15) 

Production capacity constrairns (see also Model (C6)): 

(0P1.17) 

^ 53 (Ar) ^PRODj'^cap^ {k) 

p,t,k 

30 

Storage capacity constraints (see also Model (C6)): 
(OP1.18) 

^ E Pi 'INV/ ^storage J Ik) 

40 

lntroducir)g setup costs: 

The operational model can be extended so as to include setup costs (and/or setup times) as follows: 
The term 



is added to the objective function of Model (0P1). 
50 Appropriate set of constraints should t>e added as well; for instance: 
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(0P2.1) 



5 



SETj 



(0P2.2) 



10 



PRODj^'SETj 



IS 



lYvs constraint is pertinent if product j requires a new setup in each period it is produced. (M a large** number.) 



(OP2.3) 



20 



(with SET^j initialized according to the productionAion-production of product j in the last period before the planning hori- 
zon). The intuitive behind this constraint is that if a product Is produced in a giv^ period, no setup is required at the 
2S sut>sequent period. 

Maximizing Short-Term Level off Service: Model (0P2) 



The purpose off this model is simitar to that off its long-term counterpart. Model (C2). In the same spirit off that model 
(C2), we change Model (0P1) as follows: 

Algorithm Steps 

3S 



S.T. 

{0P2.1)(0P1.1) 
(OP2.2){OP1.2) 

45 {OP2.3)(OP1.3) 
(OP2.4) (0P1.4) 
(OP2.5)(OP1.5) 
(OP2.6) (0P1.7) 
(OP2.7) (C2\4) 

so (OP2.8) (C2\5) 
(OP2.9) (C2\6) 
(OP2.10) (C2'.7) 
(OP2.11)(C2'.8) 
{OP2.12)(OP1.5) 

55 (OP2.13)(OP1.17) 
(OP2.14)(OP1.18) 



Description 



30 



(0P2): 



40 
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Remarks 



Constraints (OP2.7)-(OP2. 11) use the piece^wise finear approximation to the Standard-Nomnal cumulative distritxi- 
tk)n fmction (CDF), see below. 
5 For exptanation about the coefficients W|. see Model (C2)^|. 

Note that in thm case, in contrary to Model C2, the problem e not separable in I. This is due to the capacity and storage 
constraints (OP2.13) and (OP2.14). respectiveiy. 



Minimizing Average DC Echelon Inventory Levels: Model (0P3) 

10 

Description 

This nfKxIel is analogous to the long-term nrxxJel, (C3). 
We modify Model (0P1) as follows: 

75 

Algorithm Steps 



Step 1 : solve the follGwing problem: 
(0P3): 

20 



25 S.T 

(OP3.1) (OP1.1) 
(OP3.2) (OP1.2) 
(OP3.3) (OP1.3) 
(OP3.4)(OP1.4) 

30 {OP3.5)(OP1.5) 
{OP3.6)(OP1.6) 
(OP3.7)(OP1.17) 
(OP3.8)(OP1.18) 
Step 2: For each DC I: 

35 Compute the values 




50 
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MODEL 


WHERE USED 


Inventory positioning itlodels for multi- 
item and two echelons: 

Setting inventory requirements 

Estimating stock-out probability for a 
given replenishment quantity 


Strategic 
Planning/ 
Operational 
Planning 


Strategic models for VMR contract setup: 

Computing maximal average service levels 

Minimizing average DC echelon inventory 
levels 

Computing optimal operating parameters 

Checking compatibility of a given set of 
constraints 

Determining production and delivery 
schedule 


Strategic 
Planning 


Operational models 

Determining joint product ion -de livery 
plan 

Maximizing short-term service levels 

Minimizing average DC echelon inventory 
levels 


Operational 
Planning 



Table 13 
Usage of VMR Models 



Component Procurement Policy De/elopnnent (CPPD) 230 
Objective 

Determine wtiich procurement policy should k>e used for which component 
Scope 

All components in planning bill of materials. 
Features 

Heuristic to tdeptify the procurement policy to use for each component. The polides considered are: Just in Time; 
Bulk purchase, managed via stock policy, such as (s, S); and MRP calculus implying periodic purchase orders. 

Rnished Goods Distrftxjtion Network Design (FGND) 292 

Objective 

Determine ttie numt}er. kx»tk>n and capacity off distntxitkxi warehouses from a given set of potential kKationSw 
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Scope 

Distrftxition network exctuding VMR arrangments. ^ 
5 Features 

Use market demarxj projections to reengineer the existing distribution network. 

Gobal optimizatkHi of system-wkie costs including intx>und /outtxxind transportation, fixed and variable waretious- 
ing, and Inventory carrying costs. 



10 



Model Engine Utilities 22 



In addition to ttie seven nrKxJules defined akx]ve, ttiere is also a ^up of general purpose numerical routines ttiat 
are not spedfk: to any of the above seven modules. These routines are collected Into a design element referred to as 
IS the Model Engine utilities 22. as shown in figure 35A. Examples of the Model Engine utilities 22 include generic linear 
programmirig solvers, and statistk^al analysis routines 

An Approximation of the Standard Normal Distrflsution 

20 Function 

In this section, we suggest few continuous, piece^wise linear approximations for the cumulative Standard Normal 
distribution curve. We use the following notation throughout: 



25 (A.l) 



*{z) ^ 



30 



0 ifOoS-»<z<ei 
M M 

1 \ ife^iiz<e„e+« 



This function consists of m segments, &=s1 m. Each segment s, ranges from t^eak-point to break-point 6^. The 

sk>pe of segment s is derated by dg. Hence, any segment s can be written as the linear functbn ag+ds (6^ - 6^.1). In our 
35 model we limit the functions to be continuous (although unnecessary), thus having 

(A. 2) 



40 



a . 0 for s=l 
JL^i (e^-e,.,) for s^2 



Note that in order to define the piece-wise linear function we only require the values 6^ , s=1 .....rrvl and s=2 m-1 

45 (since d i=dm=0)- 



so 
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Type 


1 1 Remarks 




Symmetric, 


1 




-2 7 


2~ 


0.039923, 


Enables to reach 




7 segments 


3 




-1.8, 


3= 


0.164589 


reasonadble level of 


5 




J 




-0.9, 


4~ 


0.351044, 


accuracy over all 






i 




0.9, 


5™ 


0.164589 


argument ' s values . 






5 




1,8, 
2.7 


6* 


0.039923 






Symmetric , 


1 




-2 7 


2" 


0.057692, 




10 


5 segments 


2 




-1.4, 


3^ 


0.660714 


the 7 segments, but 




0: 


1 ■ 


= 1.4, 


0.057692 


recxuires less binary 








s 


2.7 






decision variaUales. 




Asymmetric , 


1 




-2.5, 


2** 


0.096904, 


Reaches good accuracy 




7 segments 


2 


9 


-1.1, 


3" 


0.331213, 


levels for the 






3 




1.1, 


4 = 


0.151834, 


highest cumulative 


IS 




4 




1.7, 




0.063973 


values . 






5 


S 


2.15, 


S~ 


0.021037 








6 


SS 


2.9 









Table 14 



Linear Programming (MILP) 

25 Consider an LP/MILP which mlmmlze8 a (linear) function of the decision variables X=(Xi X^) and their 

piece-wise linear functions FiP(i) F^PCm), M ^ N. That is, an objective function of the type 

(B.l) 



MinTc,X,^Td,F,{X,) 

ni 2-1 



35 with all di>0. Similarly to the variables ,...,Xm,...,Xn , the functions (Xj) can appear in the (linear) constraints without 
any limitation; i.a the corYStraints are of the type 

(B.2) 



46 For simplicttyp but without loss of generality, we assume Msl . Ateoi for darrty. we rename the variable X^ » T . We thus 
describe a techn'que that transforms the function F(T) into a new decision variable, say H, such that the r^ationship 
H=F(T) is maintained for any solution obtained t)y solving the new MILP. 

Algorithm Steps 

50 

Let the function F:!JC~^3C be as tbilcws: 
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(B.3) 



FIT) = 



10 



M 



r=To-o 
To30<riTj 

M 
M 



F Gons^ of m segments: segment s is given by [Tf^.^ , ]. We now introduce the following 2m decision variat}les: 
75 Yg - Is a continuoim variat)le (Y^e !^*) that represents the part of segment s "covered" by T . s= 1 m ; that is. 



20 



(B.4) 



yg=max{mln{T„. 7}-t ^.^ ,0} 



Is - Is a Binary variat)le (Is^fOpI ,2,...}) that Indicates wh^er ) that indicates whether T covers any positive part of 
segments; that is. 



25 



(B.5) 



^ JO if r>T_^ 
* 11 otherwise 



30 



To modify the current LP/MILP we do follow the steps t>elow: Replace each F(T) by the term 
. (B.6) 



35 



m 



8»1 



40 



Add the following constraints: 

Yg (s=1 m) are the split of T into the segments. 

Hence, 



{B.7) 



45 



To maintain (B.5), 
so (B.8) 



Other constraints: 
55 (B.9) 



(B.10) 



1^1^^^', s=1,/C,m-1 
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/ge{0,1}; 5=1.^,^ 

Mean 

5 This algorithm oornputes the statistical sample mean of a given tinra series for a given period of tima 
The Input lor the routine is the time series . and time periods that the me^ 
sample mean quantity 

^ n 



10 ^^ji^^' 



IS 



Standard Deviation 

20 

The algorittvn computes the statistical sample standard deviation of a given time series for a given period of time. 



25 



The input for the routine is the Hme series X, and time periods n that the standard deviation is computed over. 
The output is the unt>iased sample standard deviation quantity ay. 

30 

Moving Average 

The algorithm computes the moving averages for a given time series for a given period of time with specified aver- 
aging periods. 

35 



40 

The input for the routine is the time series X, Hme periods n that the moving average is computed ever, and the moving 
average period length K. The output is the moving average quantity 



Seasonality Factors and Trend 

50 

Seasonality Factors 

The algoritiim computes the seasonality factors for a given time series for a 1 2-nrx>nth year period. The Input for the 
routine is ttie time series, arxJ time periods that the nwving average is computed over (at least two seasonal cycles). 
55 The output is tiie seasonality factors. 

Trend 

The algorithm computes ttie trend information for a given time series for a given period of tima The input for the 
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routine is the time series, and time periods that the trend is computed over. The output is the trerxi value of the time 
seriesw 

There are several cOtferent methods to calculate the seasonality factors and the trend in a time series. The most 
popular ones include Winter's conventional linear and seasonal exponential smoothing, and (multiplicative) decorrpo- 
5 sitton method developed t>y the US. Census Bureau, and Hs variant X-1 1 method). 

Correlation Coefficient 

This algoritfim computes the correlation coefficient for a given pair of time series with property defined time periods 
10 (there might be certain shifts in twe periods In the two time series). 

r{x, y) = "-"^ 

'£(x,-x)^(Y,-y)' 

\ t-1 



20 The input for the routine is the pair of two time series X arxJ Y and corresponcfing time perkxis n used to compute the 
correlation coefficient for the two time series. The output is the correlation coefficient r(X,Y). 

Curve Interpolation 

25 This conventiorial algorithm determines a curve with desirable shape to link a set of given points on a 2-dimensional 
space. The input for the routine is the set of given points, and the desired curve shape. The output is the curve that sat- 
isfies tfie required condition& 

Weighted Sum of Two Time Series 

30 

The algorithm computes the weighted sum of two time series. 

35 The input for the routine is the two time series X arxi Y, tfie weight factors a and p and the given time periods n. The 
output is the weighted sum time series 



Coeff tctent of Variation 

45 This algorithm computes the coefficient of variation for a given time series usivg unbiased statistical mean and 
starxlard deviation. 




The input for the routine is the time series X and the given time periods n. The output is the coefficient of variation for 
the time series Cx. 

55 Goodness-of-Frt (Measure of Accuracy) 

This algorithm computes tfie goodness-of-fit (measure of accuracy) for a given pair of time series: one is the origi- 
nal time series and tfie other is the simulated one. The input for tiie routine is the pair of two time series, and corre- 
sponcfing time periods i^ed to compute the goodness-of-frt for tfie two time series. The output is the goodness-of-fit 
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(one measure of accuracy) for a given simulated method. The measure of accuracy can take one of the follcwing forms 
(assume tfiat X^XJi " Is the original time series, F=(Ft)i " is the forecast time series and e^ = XpFj are the error terms): 
Mean Error: 



5 




Mean Absolute Deviation: 

10 




15 Mean Squared Error: 

MSE-l^^ el 

20 

Standard Deviation of Errors: 



Percentage En-or: 

30 X ~F 

Mean Percentage Error: 

35 

40 Mean Absolute Percentage Error: 

45 



Regression Equation 

50 

This conventional algorithm computes the coefficients of a regression equation for a given set of time series. We 
will cfK>ose a standard computational routine to calculate these coefficients. The input to this routine is the s^ of time 
series. The output will be the calculated coefficients of the regression equatioa 

55 Supply Chain Frame Manager 24 

Overview 

A Frame 16 is designed to integrate User Interlaces, nxxlels, analysis routines and data in order to address a set 



25 A 
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of related decision ^es. Hie Supply Chain Frame Manager 24 constitutes the backtxxve of the DSS 1 0 through which 
the User Interfaces, the models In the modules and the data are connected. The Supply Frame Chain Manager 24 facO- 
itates the integration of the client side of the system, with which the user interacts, with the server side of the system 
where the modules and the DSS Datak>ase 12 resida 

s The Supply Chain Frame Manager 24 is responsble for two types of integration: System Integration and Functional 
Integration. The System Integrator 310 (see figure 34) is responsS>l6 to interpret the dienfs request, dispatch the 
request to the appropriate servers and to coordinate the computation load and data access. The Functional Integrator 
312 provides the functionality associated with cverall supply chain instead of individual frama These functionalities 
include Supply Chain Configuration. Domain Management user access or privilege administFation and performance 

10 monitoring or simulation. 

System Integration 

The Frame Manager 24 is responsible for the client-server integration in the DSS 10. In this aspect, the Franne Man- 

15 ager 24 provides the linkage between the Frames 16, Model Engine 20 and the DSS Database 12; responds to the 
decision requests from the client programs by accessing the models and data; and maintains the 'component objects" 
(ag., object linking and erTi>edding OLE objects) that share functkxialrty b^ween different Frames 16. Based on ttte 
dedskm requests, the Frame Manager 24 launches the appropriate object with the appropriate data, manages the 
requests from different clients for the same servk^e and executes the appropriate server programs. The server pro- 

20 grams execute the request, and retto-n the results to the Frame Manager 24. The Frame Manager 24 will interpret and 
retum the results to the Frames 16. 

The high level architecture of the System Integrator 310 is shewn in figure 35 and includes a Client Manager 320, 
a Request Interpreter 322 and a Server Manager 324. 

The architectural design of the Frame Manager 24 r^lects maximum flexibility and robustness of the DSS 10. The 

25 client skie includes all the User Interface 18 of each Decision Support Frame, such as Demand Management, Supply 
Management, etc. The Frame Manager 24 includes two major pieces, the Functional Integrator 312 and the System 
Integrator 310. Two other components running on the server skle are Decision Support System Datat)ase (DSS Data- 
base 12) and the Mathematical Model Engines 20. The client program 314 talks to the Frame Manager 24. The Frame 
Manager 24 is the one responsible to call indivkJual components running on the server to fulfill the dienf s request 

30 For example, a user is working on a PSI frame to devek)p production plan for a specif k; scenario. After deckling sev- 
eral key parameters, the user wants to check on the production capacity. The user makes this request from the User 
Interface 18 (dick a button or select a menu item). The request is sent to the Frame Manager 24. The Frame Manager 
24 interprets the request and determines that it needs to trme the Capacity Checking Model to get the answer. (In a 
more general case, it nrtay need to call more than one Model to accorrplish the job.) Then the Frame Manager 24 deter- 

35 mines whe^er a model Server already running and on whk^h machine it is running. If there is one, it serxls the capacity 
checking request ak>ng with the necessary data, to that server. If there is no Server running at that time, the Frame 
Manager 24 will start up one on a selected machine and sends the request thera Sophisticated dispatching polk^es 
can be irrplemented at the Frame Manager 24 to balance the bad or improve response timea After the Model Engine 
20 finishes the job, it returns the result to the Frame Manager 24. The Frame Manager 24 then synthesizes the result 

40 and returns the result to the client. 

When the Frame Manager 24 calls the Model Engine 20, it has two options in terms of passing the data. Rrst. it 
can obtain the data from the DSS Database 1 2 and pass it to ttie Model Engine 20. This will be done when the amount 
of data that need to be sent to the Model Engine 20 is not very larga The advantage of this approach is that the partic- 
ular Model Engine 20 does not require the capability to access DSS Datab^ 12. But the data has to travel from DSS 

45 Database 12 to Firanrie Manager 24 and then from Firanrie Manager 24 to the Model Erigine 20.^ 

data to the Model En^ne 20 is for the Frame Manager 24 to only pass the k^ information directty to the Model Engine 
20. Then the Model Engine 20 accesses the data directty from the DSS Database 12 i^ng the key intonnation. This 
will be used when the amount of data needed by ttie Model Engne 20 is quite sut>stantial, ag. a situation of solving a 
Linear Programming model. The k^ infomnation passed from ttie Rame Manager 24 to the Model Engine 20 will 

so include the k>cation of the DSS Database 12, anfK>ng others. 

The Client 314 only interacts witti the System Integrator 310 part of ttie Frame Manager 24. The Functional Inte- 
grator 31 2 part of the Frame Manager 24 provkies the functionality through the System Integrator 310. The relationship 
between the FuKtional Integrator 312 and the System Integator 310 is logically the same as tiie relationship between 
the Model Engine 20 and the System Integrator 310. 

55 The System Integrata 310 in turn is composed of the Client Manager 320, ttie Request Interpreter 322 and tiie 
Server Manager 324. The Client Manager 320 manages and monitors the client connection. For exarrple, it may dis- 
connect a client if the client's machine is down or if the client is inactive for extended period of time. The Server Manager 
324 manages the server skfe connection. It is responsble to start up and shut down servera It is also manages dis- 
parching. The Request Interpreter 322 is ttie one that ttie client directly interact witti. It wilt parse the client request and 
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generate request to the servers. It will consult witti the Server Manager 324 before maldng connecticHi to one spectfic 
server. 

The high Iwek object representation of the system integrator 31 0 portion of the Frame Manager 24 is shown in fig- 
ure 36 and the high level architecture is depicted in figure 37. The implementation documentation can be found in 
5 AppencfixC. 

Functional Integration 

The Functional Integrator 312 enables the advanced user to define the supply chain configuration, manages user 
10 access and privileges, supports and enables the customization of the DSS 10, manages domains to support user 
defined data groupings, manages user defined Sc^iarios 78 and ensures data consistency across the DSS 10, and 
dynamically nix)nitors the impact of the user^ decisions on the perf6rmar)ce of the entire supply chain by using supply 
chain simulation. 

IS Supply Chain Configuration 

The Supply Chain Ftame Manager 24 allows the advanced user to specify the corf iguration of the supply chain. 
The advarK»d-i^er will be at)le to specify the structural (static) elements of the supply chain. These include: Customers 
or Equipment; Products or Repair Itenre; Components; Production Resources or Repair Resources; For each of these 

20 Structural elements, the advanced user will k>e able to define the various attrSxites such as; Names and the values of 
features; Group definitions; and Nodes and locations. 

In addition, the advanced user will be able to define the inter-relationships k>etween ttiese structural elements. 
These interrelationships irKlude: Distances, costs, and flow limits on the arcs between the various nodes of the net- 
wortt; Cu^omer-Product-Resource (Equpment-Repair Item-Resource) relationship matrix; Bill of Material structure 

25 that relates components to products; and Production Matrix ttiat relates production resources (repair resources) to 
products (repair items). 

The data flow diagram associated with tf)e Supply Chain Network Configurator 330 is shown in figure 38. 
User Access and Privileges 

30 

The DSS 1 0 is a secure system where a userid and password are required for access and is managed by a User 
Access arxl Privileges Manager 331 . An account consists of a userid, password arxi membership in various groups. A 
user derives rights from group membership that can t>e individually amended. The DSS System Administrator is 
responsble for assigning each user to a group and assigning rights to every new account. The lowest access possil^le 
as allows read only access to one specific frame, with no ability to save Scenarios 78 or domains. Each tat>le in the DSS 
1 0 database 1 2 has a designated owner. Only ttie owners are allowed to update the DSS Datat>ase 12. A scenario can 
t>e used to update the DSS Datat>ase 12 wtien the user wtio generated it is the owner of the data tat}le tfiat needs 
update. 

40 Ci^tomization 

The DSS 10 is customizable to the application and environment where the tool will t>e used. The customization 
involves: Terminology and nomenclature, ModiJes and models in the Model Engine 20. Displays and reports, arxi 
Graphical User Internee objects. 

45 The first two aspects of customization are administered by the analyst^ystems administrator. For the last two 
points of customization, the user has the flexitNlity to customize dsplays. reports arxi GUI objects. The DSS 10 uses 
ttie proper terminology in the User Interface 18 for the information presented to t>e dear and intuitiva The DSS 10 con- 
forms to the user's environment and noniertdature. The DSS 10 uses a tat)le of terminology to implement the nomen- 
clature suitable to the iter's application environment. Images on kxjttons as well as text are dynamically adapted to the 

50 local environment at either the time of installation or execution. Screen appearance elements, such as colors and fonts, 
are modifiable through a User Preferences window. The user has the ability to change the layout of screen elements. 

Domain Management 

55 The Supply Chain Frame Manager 24 provides the user with the ak>ility to define combinations of products, custonf>- 
ers, and resources to be reused in the context of various analyses. These are called Data Domains and are managed 
by a Domain Manager 332. 

Data Domains provide a convenierrt mechanism for the user to define the products arxi customers with which (s)he 
is interested in woridng. For example, an account manager can define a data domain ttiat consists of the customer 
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accounts that (s)he is responsSile for. A data domain is a set of customer, product or resource combinationSw Data 
Domains may be used from different Frames 1 6. The data domain can be defined at various levels of aggregation (res- 
olution) along ^ch dimension: Product/jproduct group, customer/customer g^oup and resource/iresource group. A data 
domain is independent of a data source (forecast, point of sales, shipments). The data sources are determined tTy the 

5 type of analysis that is performed and are therefore contingent on the frame where the data donnin is used. For exam- 
ple, a domain can be used in the context of the sales promotion analysis furtctionality and could also t>e used for fore- 
casting: diff^ent data sources win be used in order to perform each analysis but both refer to the same data domain. 
Not attaching a particular time range or data series to the Data Domains fadlrtates their portatxiity from function to func- 
tion and frame to frame. The user is allowed to build, edit arxi delete Data Domair^ that are owned by the user. In sbM- 

10 tion, the user is allowed read^ccess to the definitions of the Data Domains of other users. This facilitates a set of users 
to perform similar analysis and share carefully constmcted Data Domain& The Data Domain Database corrprises two 
tables: Domain Description and Domain Definition. From these two tables, the list of available user domains and the 
memb^ tuples of each domain can be created and displayed for the user. The domain n^agement interface can con- 
sist of muttple tree-views. Each tree-view r^resents tiie logical groi|>ing of o^tomers, products or resources. From 

75 each of the tree-views, the user can select the product, customer, or resource combinations and add the selection to 
the domain. The User Interface 18 should optionally reflect the data avaDability, and the intrinsic relationshp between 
the customers, products, and resource& For example, if the user chooses a specif ic customer first, he should be able 
to choose only the products that are sold to tNs customer (or any product, depending on his preference) to make a 
domain. Since a custorner (or product or resource) can bebng to rnuttiplecustorner (or product or res^^ 

20 user should be able to visualize the groups in which the customer (or product or resource) is a member. Thte can be 
visually implemented by reversing the tree-view, based on user selected customer (or product or resource). This tree- 
reversal will display the bottom-up version of the tree, rather than the usual top-down. Data Domains can also be 
dynamically constructed based on the features of the product. For example, a PSI user can use the domain manage- 
ment tool to define that a data domain to consists of Televisions with 1 9" saeen and GR3 A chassis. The tool will tfien 

2s generate a data domain that consists of all the televisions with these features. The data domains contains the data 
groups which a DSS user is interested in working. For example, a plant manager can d^ine a domain tfiat consists of 
products and production resoiffces. An air force commander can define a domain that consists of airaaft arxJ Bne 
repairable units. The domain can t>e defined at various levels of agg'egation aSong each cSmension. Once a domain is 
defined and saved, it can t>e retrieved and used in the context of various decision analyst& Rgure 39 shows the process 

30 of using the Domain Manager 332, and also shows the operations of the Domain Manager 332. 

Scenario Managenient 

In the corrtext of tfie cfifferent Frames 16 users generate changes to datat)ases or instances of visual objects that 

35 can be saved as Scenarios 78 which are managed by a Scenario Manager 334. 

Scenarios can contain: edited data, results of analysis, graphs and charts, and performance metrics 
The Supply Frame Chain Manager 24 supports the fbltowing functions regarding Scenark>s 78: 
Save: Scenarios are saved in the kx:al cteAabasa 
Load: Saved Scenarios are toaded. 

40 Edit: Saved Scenarios are modified. 
Del^e: Saved Scenarios are deleted. 

A Scenario 78 can be used to update the DSS Datat>ase 12 when the user who generated it is the owner of the 
data table that needs updata The Supply Franie Chain Manager 24 maintains the data consistency across the entire 
DSS 1 0 by restricting the ifxlate of the DSS Database 12. Scenark)s 78 have note f ieMs to alk)w the user to enter free 

45 form commentSw Scenarios 78 should have a date starrp to indkate the time of last nrxxiifkation. Scenarios 78 are typ- 
ically defined within a franrte and are associated with a user. Scenarios 78 are specifk: to users but can be accessed in 
the corrtext of different Frames 1 6, provkfing that the user has the adequate access privileges. This enables the output 
of an analysis in one frame to be saved as a scenario and used as an input in tiie context of anotfier frama Scenarios 
78, while belonging to spedfk; users, can be shared between users. A scenario may be deleted only by the user who 

50 aeated it or the system administrator. A user shouU have the facility to load the scenark) from different workstations. A 
user shouM also be allowed to load portions of a scenark) into a different frame. For example, a user is at)le to save the 
topKkMvn and bottom-up forecasts from the Demand Management Frame 130, and load the top<k)wn forecasts in the 
PSIFrarnaTheDSSIOshouUwamtheuserincaseofdataincovrpatibility. Au models and ttie 

parameters tfmt were used to modify loaded data. The user is then able to apply these models and parameters to dif- 

55 ferentdatasGtew 

A frame 330 has several forms 332 associated with it as depicted in figure 40. If the user attempts to dose a form 
on whk:h data 334 has been changed, the user will be prompted to Save the changes to a scenario. Abandon Changes, 
or Update the actual database. Updating the actual database requires necessary access privileges. A Scenario 78 is 
anchored to a frame, and can have multiple fbnns associated with it. A Scenario 78 can t>e k>aded into the frame to 
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which it is anchored, in which case, all the data and other Information win automatically be loaded into the appropriate 
locations. Alternately, a Scenario 78 can t>e opened to access specific data that are contained in the Scenario 78. This 
feature will enable the user to load the data aeated in a different frame to a different frama To ladlitate th^ implemen- 
tation, forms are specified to have a pre-spectfied rumber of data-'pockets." Bements of a scenario include: 
5 Header information for each of tfie data pockets in ^ch of the forms of each of the Frames 16. For example, DM- 
1-[1]=POS1245=Point of Sales Information May 25, 96; DM-1-[2]=TD1245= Top Down lnfDrmatk>n May 25, 96; and 
DM-H3]=:BU1245= Bottom Up Information May 25, 96. 

Model and param^er information. For example, ARMA with (1,1) applied to Top Down data. 
Graph and parameter information 
10 User comments 
Date stamp 

Performance monitoring using simulation 

15 Two levels of integration required in supply chain Decision Sifsport Systems have been embedded in our DSS 
architecture; data integration and dedskxi integration to pruvkJe a Network Sinujlator 350 (see figure 37). The former 
has been obtained t)y having a common Dectskxi Support System (DSS) Database 12, from which input data to the 
decision modete are retrieved and outputs updated. By having such bt-directiortal data f kjws t>etween models arxJ the 
Database 12 a complete data level integration is realized. In orderwords, an decisk)ns are based on consistent and up- 

20 to-date infonnation. This is the primary level of integration for a supply chain DSS 10. 

The secondary level of integration is the dectskxi integration. The purpose is to avoid sidK)ptimizatk>n among func- 
tioruil processes. An ideal case wouM t>e to fwe a "meta analytical dedston nxxJel' which coukJ optimally solve the 
errtire supply chain wide problem. Witti the state of the art in dedskm sciences and computing, this is not . Thus, in our 
DSS architecture, various Frames 16 are Gnked by the performance simulator. For instance. Forecast Data 146 from ttie 

25 Demand Management Frame 1 30 is used in PSI planning and VMR 250 frames, VMR schedules are entered to the PSI 
planning and so on. With this approach, it is necessary to have a supply chain wide perfonmance simulator to monitor 
the effects due to the systerns dynamics along the sijpply chain to provide a functional integration. The purpose of such 
an Integration is to provide the user visibility beyond his functional boundary in order to fadlitate a feedback control. This 
feedback will make it possible to dynamically monitor the impact of hisdectskm on the performance of the entire supply 

30 chain. 

The discussion below begins with t}ackground on dedsion integration and the system architecture. Then, the 
underlying supply chain simulation modeling k>gic with regards to data ikw and process f k)w are described. Rnally, 
originality of such an approach to use a supply chain simulator for the DSS integration is discussed. 

35 High Level Architecture 

The Simulator 350 reskies at the Supply Chain Frame Manager 24 as a Functional Integrator 312 together with the 
Network Configurator 330 and Domain Marker 332 as shown in figure 37; Supply Frame Chain Manager - Kligh Level 
Architecture. The Simulator 350 can be initially configured with product f k3w. network structures and domain information 

40 with the other modules of the Functional tnte^ator 312. Thea the Simulator 350 will read major dedskxis from the incfi- 
vidual Frames 1 6 that will have impact on the total supply chain performanca Monte Cario simulation win be carried out 
driven by demand processes captured from the domain information and replenishment and PSI decisk>ns from the DSS 
Rames 16. Total systems periormance representing the supply chain dynamk;s will be tracked according to the per- 
formance matrices specified in our DSS specifk:ation. These mainly cover cost and service tradeoffs including fill rates 

45 and resportsetirnes. The peribrnriance will be rnorvtored in aggregatkxi according 

ebns, distribution channels and the total system. In essence, the architecture fadlitates the primary objectives of com- 
plementing dedSKMi integration amonQ nxxJels to provide a cross-functional optimization. 

User Interface 

50 

User Interface 18 of the performance Simulator 350 wiH have three major features; network configuration, dedskxi 
and parameter settings arvi the simulation and monitoring. 

Network Configurator 

55 

The system will invoke ttie Network Configurator 330 module of the Functional Integrator 312 at the Supply Chain 
Frame Manager 24. Detailed features and User Interfaces have k^een described in the prevknis sections. 
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Decision and Paramet^ Setting 

Parameter, frame decision settings arvi empirical demand distributions will be displ^ed in the editable screens. 
These SCTeens wDI also be accessible diring the simulation run so that the user can tnterrifit the execution and modify 
5 the param^ers interactivety. The foDcwing screens are included: Demand distritxition screens arxJ Frame decision 
screens. 

Performance Monitoring and Sinrulation 

10 The user is able to visualize the impact of the decisions taken at the level of one frame on the cverail performance 
metrics of the entire supply cfmin. The Supply Frame Chain Manager 24 supports this performance monitoring func- 
tionality. In all the Frames 16 users can easily access the "performance monitoring saeen." The performance monitor- 
ing screen displays global performarice metrics that are availat)le to all users and that cannot be deleted or rtKXiif ied. 
The performance is tracked and displayed ak)ng the: channel (such as VMR. NorvVMR, ^c); echekm (such as sup- 

15 plier, plant DC arxJ stores); individual nodes; and the total system. TTie performance monitoring screen also contains 
user formulated performance metrics that are customizable and availat)le only to the user who formulated them. 

The Supply Frame Chain Manager 24 stf)ports the following functions for user formulated performance metrics: 
Formulate: a new user-formulated performance metric, Edit an existing user-formulated performance metric, and 
Del^e: a user-formulated perfamance metric. The function "ediT arid "delete" are restrk;ted to the user who defined 

20 the performance measura 

The value of the performance measures can be updated each time the user modifies the value of a f'^ thekx»l 
database associated with the frame in whk^h the user is working or by using an explicit recalculate function or at user- 
specified time intervals. 

Users can choose 'a tk:ker-tape" to always cfisplay the current values of i^er selected k^ measures. 
25 The User Interface 18 is designed to support the conv^onal "Visual Interactive Simulatk)n (VIS)" approach. 
According to this approach, the sinrujIatkMi can be carried out not only in the batch mode but also in the event-by-event 
or period-by-perkxi mode. The performance metrics could K>e viewed and parameters adjusted interactively. To facilitate 
this approach: 

Inventory, service level and cost profiles for each aggregated measure (such as node, channel or echek)n) will t>e dis- 

30 played as time series graphs. This will highlight the systems dynamics along the chain. 

Summary performance matrk^es will be displayed in the summary report saeen or saved to a file. 
Simulatk)n Logk;: Data Row Descrptk>n 

The supply chain simutatkxi nxxJel primarily mimk;s the material arxi information flow controlled t)y the frame deci- 
skxis ak>ng the supply chain (see figure 41). The Simulator 350 ts built around data tables for each rxxJe whrch are 

35 linked according to the informatk>n and product fkTw. These data tables are stored as simulated data in the system. 

In the initializatKMi phase, these data tables will be populated with inventory informatk>n including inventory posi- 
tk}n, on hand, on order and schedule receipt Thea these tables are connected using pointers according to the network 
structure, order and product flow directk)n& Then, demand and lead time informatkni is k>aded from Demand Manage- 
ment Frame 130 through system integrator arxl appropriate distributk)n is built Using the distritxjtkxis, customer orders 

40 are generated according to the demand processes at the customer facing echek>n and replenishments are triggered 
according to the control rules atortg the logistics pipe line for each event due time. 

The major inputs required are the decisk>ns that will effect the total performance of the stpply chain. The follcwing 
are included: FGDND or r4etwork Configurator - Network design and Product fksw; Demand Management - Forecast 
arxJ forecast errors; V^or Managed Replenishment - Replenishment policy. Target inventory, and Delivery frequerv 

45 cies: PSl Planning - P line and its w*atk)n, &n6 V Gne and its variatkm; Supply Management; and Corrponent inventory 
policy and parameters. 

Depending on the configuration of the networK other supply chain system parameters such as FG inventory policy and 
parameters may also be needed for the non-VMR channel. 

The outputs from the model are based on the periormance assessment plan of the DSS 10 for a commercial setting 
so including the fdlowings: Supply responsiveness, Orvtime delivery performance RU rate, FG inventory levels. Compo- 
nent inventory levels. Order cyde time, and Rnandal measures. 

The Simulator 350 buikis up the abcve performance metrics from the event-le^fel (lowest) measures. This "t>ottom- 
ip" approach in simulation makes it possit)le to support user formulated performance matrices that will be customiza- 
ble. 

55 Sinrulation Logic: Process Row Descriptk>n 

A more detailed process fk)w of the simulatkm engine can be descnl>ed in terms of either the demand processes 
or the control rules. Two basic control rules consklered in our DSS 10 are production (reconciliatk>n) polk;ies and 
replenishment (inventory) policies. 
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Demand Processes 

The performance of the total sippty chain nrtainly depends ufxvi the control policies and parameter settings along 
the multilevel material and information flews from the supplier to customers. Both independent and dependent demand 
s processes will t>e supported. They cfictate the way requirement at each node is generated. In the independent demand 
custonrier orders are generated for all nodes from random distrixjtions de^oped from the Forecast Data 146 at each 
noda In the dependent case, customer order generation from the random dtstrbution is applied only to the customer 
facing echelon. The demand for the higher echelons are calculated from the lower ones with the lead time offsets. 
The following systems will be driven by independent demand processes: Vendor Management Replen^ment 
10 (VMR); Continuous Replenishment (CR); Reorder Pont System (r, Q); Just-in-time (JIT); and Min-Max (s, S). 

The following systems will be driven by dependent demand processes: Distribution Requirement Planning Systems 
(DRP); and Materials Requirement Planning System (MRP). As for the case of One-fbr-one (S-1, 8) system for the 
repair systems, Poisson demand process will t>e applied. Demand generation will be carried out k>y an inverse transform 
of the specified distrtoution. For high volume itenfis, nornrialapproxirnatk^ others. 
15 empirical distrftxitions will be used. Time series forecast and its error distrftxition (or parameters) will t>e obtained as 
frame decisions from Demand Management 

Replenishnf)ent Processes 

20 Both pull versus push controls are supported. In the pull control system, inventory is depleted by demand and 
whenever it reaches the replenishment point an order is placed to a supplier. In the VMR. the supplier places a reverse 
order to the store. For the demand channel, inventory decision p>rocesses (nxxJels) lor the follcwing pull systems will be 
included: Vendor Management Replenishment (VMR); Continuous Replenishment (CR); One-fbr-one Replenishment 
(S-1 . S); Reorder Point System (r. Q); and One4or-one system for repair will be logically treated the saxne as the Con- 

25 tinuous Replenishment in the commercial settings. 

For the push (planning) systems a time-phased plan for the planning interval is established and replenishment is 
triggered based on the requirement, schedule rece^ arxi on hand inventory. For the demand channel, pull systenrs 
are: 

Distribution Requirement Planning Systems (DRP) 
30 Similariy. for the supply channel, the following pull systems will be SLf>ported: Just-in-time (JIT); arxJ Min-Max (s, S). 
The push planning systems for the supply channel are: 
Materials Requirement Planning System (MRP) 

Transportation and information flow logic will k>e ennbedded in the replenishment processeSw The capacity limita- 
tions, cost and lead time fa various modes of transportation and information flow (orders) will be checked to execute 
35 the replenishments. 

Recorxaliation Processes 

The procbx^tion planning logic refers to the way MPS is created. Given a PSI plan 1 90 for the planning horizon with 
40 possible variation, the system need to track the dynamic outcomes ak>ng the sippty chain. This will be carried out by 
generating the dynamic demand atong the demand chanr^el and corYsolidating them to obtain the simulated S* line. The 
simulated S* tine (line refers to as the time series sales infonnation) will be checked against P' (production) and r (inven- 
tory) lines of the PSI plan 190 to compute service fOI rates. Then production plan P' line will be offset k)y simulated pro- 
duction lead times. 

45 Once the actual P' line is established, component usage can be conned using the Bill of Material (BOM) tables. 
This usage is translated as requirements (demarxQ to the supply channel. Then, component f tows ak>ng the supply 
channel will k>e traced according to the respective component replenishment policies and demarxi processes at each 
node foltawing a similar k)gic as described in the demand channel. 

so User Interface 18 

One of the primary objectives of our DSS 1 0 is to provide a decision support environment that facilitates the ded- 
sion-making processes using quantitative nxxJels and associated business data The interaction between the users and 
the DSS 10 during the decision-making process can be characterized as fbltaws: The communication of process infor- 
55 mation emd management input; Fonmulation of dedskxi problems; Generation of problem solutions or evaluation of 
decision attematives; and Coordination of the abcve. 

To fadlftate the conrvnunication and coordination between the users and the DSS 10. it \& necessary to choose tiie 
appropriate User Interface 18 design paradl^. 
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User Interface Design Paradigm 

The User Interface 18 is t>ased on the conventional human computer interaction paradigm referred to as "direct 
manipulation*. In this paradigm there Is no dear separation of input and output For example, in exercising a certain 
5 rTKxlel the user may either evaluate the impact of a decision option k)y specifying the decision variables or generate the 
optimal values of the decision varlatales. In the former setting the decision variables serve as input while, in the latter 
setting, the decision variables constitute the output 

Another characteristic of the direct manipulation paradigm is the quick feeOback feature where a user initiates an 
action such as posing a particular query through direct manipulation of some interface object and the system responds 
10 with reasonable speed. 

User-DSS Interaction 

In each Dec^ton SLf)port Frame discussed previously, the users will be aided In making several decisions. The 
IS principal process underlying these decisions will serve as the basis for the design of the User Interface 1 8. 

A typical user-DSS 10 interaction (see figure 42) begins with the users reviewing 402 the initial conditk>ns and 
default values related to a dectskxi problem retrieved from the DSS Datak>ase 12. Then the i^ers communicate their 
preferences through proper selection of options, specification of parameters and values, and choice of analysis rou- 
tines. The DSS 10 examines the ir^MJts provided by the users arxl assists the users in resolving any Inconsistency in 
20 the inputs. Then, to look for the solution of the problem, the DSS 1 0 invokes the decision logk; 76 of the frama The Si4>- 
ply Chain Frame Manager 24 associated with the frame executes the appropriate quantitative models and routines in 
the Model Engine 20. The users can review fhe output through the User Interface display, and repeat the above process 
if warranted. 

The general guidelines for the preferred User Interlace design are deserved in the next subsection. 

25 

Design Guidelines 

The general design guidelines are as foltaws: 

30 User Friendliness 

Intuitiveness: Conformance to establ^ed standards. 
Integrated graphical display: Simple and visually dean graphical screen layout 
User customization: Ak>ility to customize the interface into user's desired style. 
35 Minimal typing: Use of menus, pull down lists and buttons. 

User Guidance 

Rexible sequence control: Ability to access the DSS 10 functionality without a pre-imposed sequme. 
40 Context-sensitive onAine help. 

Semantic feecft>ack: Use of visual and audk> cues for confirmation and progress. 
Use of colors for darity. focus and aesthetics. 

User Interaction 

45 

Data visualization: Visual akis to interpret data. 
Object orientation. 
Locaiyiremote concurrent usaga 

Single/group i^ge. Ability tor multiple users to cdlatxirate in dedsion making. 
so Mult^e tevelsof user expertise: Support for novk^e as well as advanced users. 

Irrplementation Princples 

Consistency: Similar look and feel" for userinterface objects across the DSS 10. 
S5 Modularrty: Reusable and obiectK>riented user-interface coda 
ConfiguratMlity: Adaptability to the specifk: user environment 
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Design Elements 

The key design elements for the DSS User Interface 18 Include; Frame GUI; and Starxlard Object Lbrary. 
Frame GUI: Since the DSS 10 will be an interactive environment, we adopt the most comnrm environment used for 
5 Interactive computing, known as the WIMP environment which stands for Windows, kxHis, Menus, and Pointers. A 
frame-spedfic graphical User Interface (GUI) in thte environment is necessary to support the interaction between the 
users and the DSS 10 in a decision process. The Frame GUI is customized using a standard set of User Interface 
objects. An example of this Frame GUI is given in figure 43. 

Standard Object Ubrary: The standard set of the User Interface objects used to build Frame GUIs is contained in a 
10 starxlard object Ibrary. The forms, positions and contents of the objects are set according to the spec^K needs of each 
Frame GUI. For example, these are the sample objects in the standard lit)rary errployed in the PSI DSS shown infigure 
43. 

Selection: to choose among various action options 
Grid: to input data and display results 
IS Chart to display input data and results graphk^aily 
CommarKi Button: to execute an actk}n 
List Box: to list user choices 

Exairple Implennentation Architecture 

20 

The basic objective of the DSS 10. is to provkJe customized dedsfon support fa the dectsk>n makers to manage 
an integrated agile supply dhsdn. It generates the folkiwing two specif k: systen^ requirements: DSS 10 shoukJ provMe 
decisbn support capabilities that work with the prevailing information systems whk^h is mainly data transactkm based 
systems. These dedsfon support capabilities may include data analysts, decision process nxxJelir^. scenario manage- 
rs ment among many others; and DSS 10 must integrate data from various sources along the Supply Chain Informatkxi 
Systems 15. This requires the DSS 10 to interact with nultiple information systems to gather raw data arxi distnlxjte 
processed data. 

These two t>ask: systems requirements motivate tfie architecture arvJ the choice of the platforms. 

30 Three-tier DSS Architecture 

In an enterprise-wide supply chain, the potential users of the DSS 1 0 are dedsion makers with different operatk>nal 
resportsbilities and concerns. The views atxMit the supply chain and functk)nal requirements for decision support m^ 
therefore vary accordingly. The data to support these functional requirements reskie often on a number of information 

35 systens possfoly with different hardware and software platforms. Consequently, the DSS 10 needs to interact wHh the 
users through a unified User Interface 1 8 to address diverse business concerns whDe it shouM also t>e capable of inter- 
fadng wHh cfifferent Supply Chain Information Systems 15 to gather arxJ distrfoute data. 

To tfiat end, we have developed a layered systems architecture design for the DSS 10 as sfKwn in figure 44 in 
whfoh all major system components interact with each other in a layered fashfoa Aside from other ben^its. the layered 

40 design makes the chofoe of platforms as well as implementation of indivklual system components relatively indepervJ- 
ent and permits standardized interfacesamong various system conrponenta The DSS ardiitecture can also be viewed 
as a three-tier architecture consistent with the commonly understood three-tier dient-server information systems archi- 
tecture consisting of the User Interface 18, the Business Logfo 350 and tfie Data Mar^gement tiers 352 as illustrated 
in figure 44. 

45 Each of the ttvee tiers in the DSS architecture has its distinctive functfonal roles and presents various levels of the 
system complexities. The platform for the three tiers is preferably cfx>sen to best fit the user's unk|ue furxTtfonal arxi sys- 
tem needs. The chofoe is complicated by the availatMlity of a nunrt>er of competitive software and hardware platforms 
arxJ the realization that there may not exist a single ''optimal" suite of platforrns. In the folfowing, however, we descrfoe 
a suite of platforms that can t>est serve the general DSS 10 needs and also be in line with the forecasted future devel- 

50 opment trerxis in information technology arxf enterprise-wkie distributed computing technology. 

Selection of DSS Devefopment Platforms 

To support the supply chain wkle dedsion making, the DSS 10 needs to be integrated, flexible, responsive and 
55 comprehensive. One major obstade. however. ^ that most of the data required by the DSS Datat>ase 12 are stored in 
various Supply Chain Information Systems 15 that are based on an dder information and computing technofogy. 
designed to support vertically Integrated organizatiorts, Ixjilt in isolation, and usually very conplex. Such systems are 
generally referred to as the legacy systens. Therefore, to meet business and systems neecte, the DSS 10 environment 
should: provkie comnxm and easily understood interfaces to all users, enhance the current business knowledge and 



102 



EP0770 967A2 



skills, model and incorporate business logic, and pronnote access to legacy data and application systems in a secure 
manner. 

The development platform environn>ent 370 illustrated in figure 45 has been chosen as the preferred environment 
to meet the atxsve requirements. 

5 In ths development environment 370, Microsoft Visual Basic 372 is used to build the unified User Interface 18 and 
the Business Logic 350 that includes the Frames 16, Supply Chain Frame Manager 24, system level services and 
Model Engine 20. Portions of the Model Engine 20 tfiat require more efficient and precise numerical computations are 
preferat)ly implemented usirtg the Visual Gm- programming language 374. 

The Visual Basic codes 372 directly interface with the DSS Datat>ase 12. The DSS Database 12 uses Microsoft 

10 Access 376 which, in turn, interfaces with the Supply Chain Information Systems 15 through either Windows ODBC 
(Open Datat>ase Connectivity tools 378 or Microsoft SQL Server 380 in a dientA&erver fashion. The Supply Chain Infor- 
mation Systems 15 can indude data servers in IBM SQL/DS, UNIX Oracle, among other formats. 

The Windows NT 382 is operating systems for the local area network server while the User Interface 18 can be in 
any Windows environment (3.1 and above) 384. 

15 In this environment it is important to estat)lish the dient^server data Gnkage between the DSS Datak)ase 12 
(Access engine) and the supply chain information system data servers. 

As descrfoed earlier, the DSS Datat>ase 12 is internal to the DSS 10 inplementation and contains only the data 
needed for the execution of ft\e DSS 10. The data in the DSS Datat)ase 1 2 is synthesized from a variety of sources in 
the Supply Chain Information System 15. The DSS Database 12 can be interfaced in a Client Mode 30 to the supply 

20 chain information sources for data retrieval and update, as needed, this dient-server interface, rather than a hard link, 
has the advantages dscussed betow. It ensures that the DSS 10 can be linked to the heterogeneous informatfon 
sources in the supply chain. This is partfoularty signifkant in the absence of an enterprise^wide integrated informatfon 
system for the sipply chain. It reduces the burden on DSS Database management by obtaining updated data only 
when necessary. It fosters independence of the DSS 10 for easy maintenance. It fadiitates development of the DSS 10 

25 for a generic supply chain architecture and minimizes applfoation spedffo customizatfon. 

The architecture descrbed herein is built upon the general dient-server concept In the following, we descrit)e the 
hardware system architecture (see figure 46} for generfo systems, in whfoh the host 398 represents the Supply Chain 
Informatfon Systems 1 5, and the PCs 400 in the Local Area Network (LAfO) 402 supports the DSS 1 0 applfoations. This 
architecture supports storing the inventfon descrik>ed herein on various types of storage including RAM, ROM, hard and 

30 floppy dsks, etc. 

In the architecture of figure 46, we assume that the hosts 398 contain the m^ority of transaction level data and they 
will communicate with an LAN 402 where the DSS 10 resides. Here, we do not make specific assumptions about the 
type of the hosts (IBM mainframe or UNIX wortcstation). On the LAN 402. there will be a 8erver(s) PC 406 and a set of 
linked dient PCs 400. Spedffoally, the functkyis of the DSS 10 can be partitioned as illustrated in figure 47. 
35 Below we descn'bethe basfo system requirements and functfons for the system components in the atxive diagram. 

LAN: 

Basic Requirements: 

40 

Local area network supporting standard protocols such as TCP/IP, IPX/SPX. Named Pipes/NetBEUI etc. 
PCs can run Windows NT or 95 

Basic Functioris: 

45 

ProvkJe the communfoation media between dient PCs to server PCs 
Perrrvt external PCs to cial irtto the network using regular telephone lines 
Allow connection to the IBM hosts 

50 Qient PCs: 

Basic Requirements: 

Have suffident speed av6 memory 
55 Have networtt connectfon (on the LAN or dial-up through telephone line) 
Can run Windows 95 or NT 
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Basic Functions: 

Serve as OLE clients 
Provide primary User Interlace 
5 Implement what-if scenario manager 
Contain localized database 

Server PCs: 

10 Basic Requirements: 

Have maximum speed, storage space, memory arxl network connectivity 
Run Windows NT. SQL Server and SNA Server 

IS Basic Functions: 

Be the OLE server 

Host ntain DSS Datat>ase 12 with a Ibrary of SQL queries 

Serve as the SNA Server to exchange data between the DSS DB and host data tat)les 
20 Implement model object Ibrary 

Contain external optintization solver 

Hosts: 

25 Basic RequirenrYents: 

Standard IBM database arxJ applications or UNIX based datak>a8e 
Support any combination of the options (Ethemet. Token-Ring, or FDDI) 
SDLC 

30 X,25.QLLC, eta 

Basic Functk>ns: 

Provide raw supply chain wide transaction data 
35 Contain EDI or other connectk)ns with customers and suppliers 
Support overall business information requirement of the company 

Example of Use 

40 User Access and Privileges 

When the DSS 1 0 is invoked, the DSS logon dialog box will t>e displayed to the user (see figure 48). Failure to enter 
a valid User ID/Password combination results in the DSS 10 immediately temiinating. Con^ect entry of a valid user ID 
arxJ password results in the DSS 10 t)eing started arxi the opening screen being displayed to the user. The user ID is 
45 visble as it is typed by the user, but the password is bkx;ked to prevent casual observation while it is k>eing typed. The 
user ID is checked against an internally maintained table to ensure authenticity and user's privilege 

Opening Screen 

50 Once the user has successfully logged on to the DSS 1 0, the opening screen is presented. Presenting the opening 
screen and deciding which frame the user is able to access is the responsibility of the Supply Frame Chain Manager 
24. The main feature of the opening saeen is a graphical outline of the si4)ply chain overiaid wHh the relevant Frames 
1 6 and showing the relevant portk>n of the supply chain. The user may nxve the nrKXise pointer over any of the Firame 
Boxes and dick within the box to launch the franfte (see figure 49). 

55 The user may also directly access the Firames 1 6 from the Toolbar buttons. The user must have the correct privi- 
leges to access the selected group, or an error message will t)e displayed alerting the user that he does not have the 
conrect privileges. 
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User Preferences 

A feature of the DSS 10 availat)le from the main DSS screen is the User Preferences Folder. This tDlder allows the 
user to change certain features of the DSS 1 0 to preferred settings. Aspects of the screen appearance, layout and tunc- 
5 tionality will be mocfifiable by the user. These preferences are saved and remembered between Afferent DSS 10 user 
sessions (see figure 50). 

Domains 

10 Select Data Domain 

The primary interaction screen for ttie Domain functionality is the Select Data Domain dialog box (see figure 51). 
The purpose of th^ dialog box is to display a list of all domains availat)le to the user. It also alleys the user access to 
dialog boxes for, editing, aeating and deleting user domains This set of functions constitutes the core functionality for 
15 the domain object 

The major features and functionalities of the Select Data Domain dialog box are disclosed below. An area showing, 
in a graphical way, the available domains. This let is built from two separate lists of domains. One set of domains is a 
default list of domains available to all users. The second set of domains is a user-specific set of domains. This set of 
domains can be created, edited and deleted by the user. The default set of domains is immutat)le. Each domain is rep- 

20 resented by a folder. Double clicking on a folder selects the folder and adds it to the Currently Selected Domain text box. 
Double clicking on a folder expands the folder and shows the customer-product tuples that are within the domain. An 
area showing the cun-ently selected domain name. A button to allow Ljoading of the cunrently selected domain. A Cancel 
button to allow the user to exit the dialog box without selecting any domain and wittKnit initiating a bad operatioa The 
Cancel is only valid for operations performed on the current dialog box. Editing operation performed during the session 

25 will persist. An Edit Domain button to allow users to modify existing domains, create new domains and delete unneeded 
domains. This functionality is only available for user-created domains and not for default domain& 

Edit Domain 

30 The Edit Data Domain function allows the user to create new, user-defined domains and add tiiem to the list of 
existing domains. In adcStion, the edit domain window allows the i^er to nxxiify existing domains and delete unneeded 
domains. The user can create tuples from a tree-like listing of all available products and product groupings and all avail- 
able customer/customer groi^^ings. The user may add as many tuples to the new domain as necessary. The user must 
give the domain a unique name and save rt It is then added to the list of availat3le domains for the user (See figure 52). 

3S Thenrajorfeaturesandtheusageolthefeaturesof the Edit Data Donmindiafog to To cre- 

ate a new domain, the user must dk^k the Add New Domain button on the tool t>ar. This will create a new domain in the 
list of existing domain and open a nanrie change box over the narne of the donrein so the u^ new domain 

a unique nanrta To add a new tuple to a dorrein the user must teve a selected donriaini^ list Next the user 

must dick on a product or product group in the product tree and^or a customer or customer 

40 and dkk the Add to Domain button on the toolbar to add the selected tuple to the selected domain. Only one prod- 
uct/|;>roduct ^oup and one customer/customer g^oijp may be selected at a tima Selecting a group will result in aggre- 
gated data for the selected group being displayed. If data for tiie members of the groip will be needed, the system will 
assist the user k>y displaying the data at appropriate resolution. However, some analysis may require that all of the data 
for the members be loaded. A shortcut key will be provided to allow the user to select all of tfra products or customers 

45 that make up a selected groupi The user may select as many tiples as necessary. To remove a tuple from the new 
dorrain. the user nruist select the tuple from the list of tijples to be added to the new domain and dnk the Delete button 
on the toolbar. To delete an entire domain, highlight the ctomain to be deleted in the list of domains and dk:k the Delete 
button on the tooft)ar. The user will be warned that this action will result in the elimination of a domain from the DSS 1 0. 
If the user dnks OK. the domain is deleted. If Cancel is dicked, the domain will not be deleted. When naming a new 

50 domain: the new domain may not have the same name as an existing user domain nor the same name as an existing 
default domain: and the domain name should be something desaiptive to the user so he will remember what the 
domain represents. The user saves the new data domain and exits the dialog box by selecting the OK Ixitton. If the user 
exits without saving the new domain, he/she will be asked whether the new domain shoukJ be saved. The user can exit 
the diafog box without saving the new data domain by diddng the Cancel button. Default domains cannot be added by 

55 the user. Default Data Domains are created and added to the DSS Database 12 by a systems administrator with tiiis 
access privilege. The user may choose between four different modes for viewing the Customer and Product trees as 
disclosed below. The Troduct View" enables the user to first dick on a product or product group in the Product tree. 
When a product or product group has been selected, the Customer tree is updated to dsplc^ only the customers and 
customer groups that are relevant The "Customer View" enables the user to first dick on a customers or customer 
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group in the Customer tree. When a customer or customer group has been selected, the Product tree is updated to dis- 
play only the product and product groups that are rele^/ani The 'Customer-Product View" enables the user to first dick 
on either an element of tfie Customer tree or an element of tfie Product tree and see the existing related elements in 
the other trea The T^eutral View" displays aD customer and customer groups and ail product and product groups with 

5 no Gnkage betwe^ them. This view allows users to select tu^es without regard for the existirig relationship t>etween 
the products and a customer. The user also has the ability to reverse the tree and shew all the parental relationships 
involving a selected element of the tree. This is acconpltshed by way of the Reversed check bcx located at the top of 
the Customer and Product trees. By clicking the check box the tree is reversed, k>ased on the cun-entty selected element 
of the tree. Either a group or an individual product or customer may be selected. The tree may then be rotated to shew 

10 thegroipsitt)elongsta To restore the view to the normal view, uncheck the check box. 

The user may deselect any selectkxi made in a Product or Customer tree by clicking tfte Deselect-button located 
above the desired tree. This win remove the highlight bar from the currerrtly selected tree element and leave all ele- 
ments of the tree in the unselected stata This is useful if the user wishes to select an element from only one or two 
trees, txit net all. 

15 

Make Product Set 

The Make Product Set dialog box gives the user an alternate way to make a domain which only consists of products 
and product groups (see figure 53). Usir^g this diatog box, the user riiay select gr 

20 tures of the products. This function can be accessed from the Edit Data Dontain dialog box by clicking the Make Product 
Set button on the toolbar. This win open tfie Make Product Set diak)g box. 

First, the user selects a product category from the product category BsL Then, the user selects a feature (or fea- 
tures) that win be used as selectkm criteria(i.e., the Brand) in a combo box in the right part of the dialog kxix. Once the 
feature selectkm is made, tfie possa>le values for that feature will appear in a Rst kxxx beksw the selected feature name. 

25 The us^ may then hts^light tfte features desired. Immecfiatety after the feature type (\.b„ Brand) is selected, a new 
blank feature type selection txxx appears to the right of the selected feature type. This aUows the user to select a second 
feature choice to use as a &electk>n criteria (i e., Sut>typ>e). Once again, the possik>le values are then listed in a list box 
t>ek3w the selected feature type arxi a third feature type selectkm combo box appears to the right of the last selectk)n 
combo box. This process will repeat until there are no more feature types related to the products. The user may select 

30 all of the choices for the feature t>y clicking the Select * button located directly below the Feature Type dialog box. In the 
following example, Ihe resulting domain conssts of products in the "PROJ" product category with txand being "Fl", "PP" 
or "S" arxi subtype being "P" or "S". The products that satisfy these selection arterta are shown in the Troducts" list. 

As the user makes selectk)ns from among the Feature choices, the list of products matching the selection criteria 
is updated in the Products list box. The user may select a set of these selected products to use as the domain, or may 

35 choose all of the products selected using the Select button. When the i^er has the desired set of products, OK is clicked 
to copy the selection to the Ecfit Data Domain dialog box. 

Scenarios 78 

40 Sceriarios 78 are the vehide for saving arid rek>adingeKperinr)erital work. Fi^ 

save a scenario to retain the what-if analysis work performed. Once a scenario is saved, it may be accessed by other 
users as a means of sharing analysis and planning results among cfiff erent users. A scenario may also be used to save 
tfie logic behind a business decision, so the factors contrftxiting to the dedskm may be analyzed at a later date arxJ pos- 
sUy reused. 

45 \Nhen the user chooses Save Scenario from the Rle menu groip. the Save Scenario dialog box is presented (see 
figure54). Atthetopofthediak>gbQxisaneditbaxsfiowing the name of the selected scenario tfie current information 
should t>e saved ta If the user wishes to create a new scenario, the name of the scenario is typed into this edit tx>x arxi 
the data win be saved under this new scenark) nanria Scenario narnes rnust t>e uriiqu 

The user has write access to a Scenario 78 to save the modified information to an existing scenarkx Scenarios 78 

50 for which the user does not have write-privileges will appear grayed-out in the Save Scenark> dialog box, and the DSS 
10 will not allow the user to save to this scenario. The user may also add a description to the scenario and tNsdescrip- 
tk)n win appear at the bottom of tfie Save Scenario screen. This is a free text area where the user may type any words 
to descrft)e the scenaria Each time the scenario is saved, the Date Updated field of the scenario is automatically 
changed to the current date and time. The scenario is saved when tfie user dkks the OK button. If the user dicks the 

55 (Cancel button, the scenario is not saved. 

If the user wshes to k)ad an existing Scenario 78 , the Open Scenario menu diok:e on the f^le menu is selected 
(see figure 55). Scenarios 78 that were aeated by other users appear with a RO tag. for read only. These Scenarios 78 
may be loaded but cannot be saved. The user may always save these Scenarios 78 to a new scenario, if desired. 
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Demand Management Rfame 

The User Interface for Demand Management (DM) Frame 130 provides the user with a consistent environm^ for 
carrying out these five activities: Demand Characterization; Bottonrvup Forecasting; Tofxtown Forecasting; Sales Pro- 
5 motion Analysis; and Forecast Perfwmance Evaluation. 

Each of these activities requires a slightiy different User Interface to accomplish the task at hand. Therefore, a dif- 
ferent saeen is used for each, aHhough they will share many common elements, tools, and procedures Within the DM 
Frame, any numb^ of activities can be operative, however, the user may view only one screen at a tima The user may 
change the view from one screen to another without bsing any data or configuration infonmation associated with each 
10 screen. 

All DM activities take place within the same data domain, although different Data Domains may be active in other ' 
Frames 16 of the DSS 10. The user can select a new data domain lor the DM activities at any time using tiie standard 
DSS 10 data domain selection dialog box. 

There are several desirat)le features convnon to each of the DM screens. Regardless of the area in which the user 

75 is working, tiie user is able to perform the following operations: save and retrieve DM configuration information; save 
and retrieve data from the DSS Database 12; save and retrieve DM data as a scenarb; display point-of-sales or ship- 
ment data (where applicable); specify limits on data time series; specify the resolution of data time series (yeariy, 
monthly, weekly); display data as ^>solute values, or as percentages of some total values; display data in tabular or 
graphical form; dear, cut copy, paste data series within the DSS 1 0 and Windows environment; and apply functions to 

20 data in a "scratch" or work area. 

Work Area Pop-up Saeen 

In addition to the decficatedsaeeris, a pop-i4> window is available to act as a scratch or w^ Data series can 
2s be cut copied, and pasted to and from this window £ind other DSS windows, as well as other Windows appfications. 
Users can use this window to process and analyze data. 

The fbllcMring sections descrit>e each of the DM screens in more detail. 

Demand Characterization 

30 

This area of tfte demand characterization screen enat)les the user to visualize the selected domain in outiine form. 
The user can then select or^ or more data streams at any level of aggregation, arKi by using the option menu, specify 
the type of data to be displayed: sales history, sales characteristics, or Market Data 140. The Market Data 140 may not 
be always available at the same resolution as the firm's Demand History Data 136. Therefore, special "market Data 
35 Domains" are aeated to fecHitate access to the Market Data 1 40. 

On the rig^ harx! side of the grid the user can choose between a set of summary s ta tis ti cs to be displayed: VTD 
Year to date; YTG Year to go; YTDL Year to date last year; YTDB Year to date budget; YTGB Year to go budget; arxJ 
L12M Last 12 months. 

Several analysis tools are available: Trerxi, Moving average. Pattern changes, Pareto analysis, and correlation 
40 between products. The output of these analyses can be displayed in tat)le or in graph. 

Sales Characteristics Screen 

A set of Sales Characteristics can be computed and displayed in a special table: average level of demand, trend, 
45 volatility, and lumpiness. Accessing this table can be dor)e through the menu under the option entry 

Bottom-Up Forecast 

The Bottom-Up (BU) forecast saeen (see figure 56) contains a Customer Table and a Product Table which have 
50 several configurable columns and data display options. BU operations and functions are accessed from the BU screen 
menu and subsequent dialog boxes. 

Customer Table 

55 Since BU forecasting is a custonr^er-driven operation, the topnfK)st table displays the customer tree for the selected 
domain. Only those domain entries which are strictty customer-oriented are shown in the customer tabia Entries are 
displayed in an outline form as they were defined in the domain. The first column in the table lists the names of customer 
groups or customers, while the remaining columns contain the total sales data for that customer. A split line in the table 
divkies historical and Forecast Data 146. The time spans for historical and Forecast Data 146 can be specified by the 
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user. 

Customer groups may be expanded or collapsed by double clicking their names in the Customer column entry. 
Product Table 

5 

TTie bottom table displays aO products carried t>y the selected customer (groip). Sales data for each product shewn 
is presented In outline form, which may be exparxJed or collapsed by doUble clicking on a product nama The entries 
beneath each product include actual orders, forward orders, arxl orientation orders. As with the Customer Jatjke, the 
table is spirt to show both historical and Faecast Data 146. The user may specify the position in the time series for the 
10 historical and Forecast Data 146. Promotion periods are highlighted on the (fisplay. 

Total Columns 

On the right side of the Product table is three columns which can display a selection of user-defined totate from the 
15 following choices: YTD Year to date; YTG Year to go; YTDL Year to date last year; YTDB Year to date budget; YTGB 
Year to go budget; and L12M Last 12 montfis. 

General Feat^es 

20 Promotions periocte are displayed highlighted. The impact of promoted verses unpromoted sales can be c§splayed 
separately in drop-off cells. The nix percentage can t>e used to disaggregate a faecast generated at the aggregated 
l^el of the customer or customer group. Disaggregation can also k>e done t>ased on 1t\e total for the year arxl some 
user defined seasonality factors when the menu option "Disaggregate Total year" is cfiosen. Time series of user defined 
"leading indicators" can be displayed for relererK:e and forecastirig purposes. 

25 

Top- Down Forecast 

As would be expected, the Top-Down (TD) forecast screen (see figure 57) is similar to the Bottom-Up Forecast 
saeen, except that the interiace is arranged for product-driven forecast operations. On the TD screen the Product table 
30 appears at the top. while the Customer table appears k>elow it Data display options and forecasting tools for TD oper- 
atior^ are accessed from the TD screen menu and subsequent dialog boxes. 

Product Table 

35 The Product table displays the list of products from the selected domain. Only those entries which are strictly prod- 
uct-oriented are shown in this tatUB, and are displayed in an outline form as they were defined in the domain. The first 
column in the tat)le lists tfie names of product groups or individual products, while the remaining columns contain tfte 
sales data for that product aggregated at the appropriate tevel. A qplit lir>e in the tat)le divides historical and Forecast 
Data 146. 

40 Then ihe user selects a product group or product from tfie Product tat>le, the list of customers carrying the prod- 
uct(s) is displayed in the Customer tat)le as descrft)ed below. Product groups may t>e exparxfed or collapsed by double 
cGcking their names in the Product column entry. 

Customer Table 

45 

The bottom talsle displays all customers who carry any of the products selected in the Product tat}le. If a customer 
carries all of the selected procfcjcts, it is displayed in a focused font othenwise it is sfK)wn in normal font Sales data for 
each customer is shown. The entries beneath each product include actual orders, fboMard orders, arxl orientation 
orders. As with the Product table, the custonier table is split to show both historical and Forecast Data 1 46. The user 
50 may specify the position In the time series for the historical and Forecast Data 146. Promotion periods are highlighted 
on tfie display. 

Total Columns 

55 On the right side of the Customer table are three columns which can display a selection of user-defined totals from 
the folk3wing choices: YTD Year to date; YTG Year to go; YTDL Year to date last year; YTDB Year to date budget; YTGB 
Year to go budget; arxJ L12M Last 12 months. 
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General Featu'es 

Promotion periods are displayed highlig^ed. The impact of promoted verses unpronrvjted sales can be cfisplayed 
separately in drop-off cells. The mix percentage can be used to disaggregate a forecast generated at the aggregated 
5 le^el of the customer or customer group. Disaggregation can also be done based on the total for the year and some 
user defined seasonality factors when the menu option Disaggregate Total Year" is chosen. Time series of user def hed 
^leading irxlicators' can be displayed for reference and forecasting purposes. 

Sales Promotion Analysis 

10 

The User Irtterface that supports Sales Promotion Analysts is txjilt around the promotion calerxJar. The promotion 
calendar shows the Bst of all the past and planned promotions for the set of products and customers defined by the 
selected domain. 

For each promotion the following is cfisplayed in the pronxition calerxiar: starting date of the promotion; end date 
15 of the promotion: promotion type; pronrK>tion dass; product being promoted; customers supporting the promotions; pro- 
motion intensity; and Impact of the promolioa 

When the user clicks on the promotion calerxlar button on the toolbar, the promotion calendar Main Display Win- 
dow is displayed (see figure 58). 

The user can select one or several promotions in the promotion calendar. For these promotions the user can per- 
20 form the operations discussed t)elow. Display shipment and POS Data 1 38 in table formats similar to the one used in 
BU and TD forecasts. Compute the promotion impact for past promotions^ Estimate the irrpact of future promotions. 
Display ^aphically the impact of the promctior^s on sales. 

If the user wishes to view the ojstonrierixoduct tuple (don^n) that prorno^ are displayed for. or wishes to limit 
the promotions shown by choosing what Promotion Type, Promotion Class and Promotion Intensity he wishes to ana- 
25 lyze, the Promotion Selection Wizaid may be invoked. The user selects the customer-product pairs that analyst is to 
take place on and can limit the selectkxi by choosing what Promotion Type. Promotion Class and Promotk>n Intensity 
he wishes to analyza When the OK button is dicked, the Promotion Calendar diak>g box is populated with all promo- 
tions ttiat match the selectkxi criteria (See figure 59). 

30 PSI Frame 

The PSI main screen is a work area where the user can experiment with different Production, Inventory and Sales 
figures and see the effects caused t)y these cfianges to eventually converge to the most desirable PSI plan 190. The 
Main PSI Screen (see figure 61) initially shows the Production, Inventory and Sales for all of the products in the user 

35 selected domain. The figures for all of the products are aggregated together and shown. The user may also select any 
indivkiual product in the aggregatkxi anti show the numt)ers for this product alone. This can be done t>y choosing the 
desired product numt>er from the Product selec1k)n comkx) box kx:ated near the top left of the saeen. The first chok;e 
in the conrt>okx3K is always All Products to alkTw the aggregaton of aUprodu^ The user may change the 

products being analyzed by selecting a new set of products from all availatHe products. This may k>e done by selecting 

40 a new domain. 

Directly folknving the Production (P), Inventory (I) and Sales (S) lines are Temporary P, S and I lines (see figure 60). 

This is a work area where the user may copy and experiment with the real P, S or I figures and modify them to create 

new Scenarios 78. Copy and Paste are enabled on this form so the user may copy the original numbers to the work 

areas. The user may also copy a time series from arKitfier part of the DSS 10 or a separate application to the temporary 
4S lines through copy arxl pasta Lastly, the user may bad data from a saved scenario to the temporary lines on the form. 

The irxiividual cells tfiat comprise the temporary work area may t>e marually edited t>y the user by dk:king on tf>e 

desired cell and changing the value in the cell. 

Also present on the work area of the form are Top-Down, Bottom Up, Customer demarxi information, a Top-Down 

minus Bottom Up (TD-BU) and Top-Down minus Sales (TD-S) lines. These lines give the user different and useful views 
so into the planning data under analysis. These lines are calculated k>ased on the values in the temporary R S and I lines 

of the form. 

The last column displayed on the screen is a sum of the data displayed on the screen for the current year. This col- 
umn remains on the saeen and does not saoll left to right as other columns are being scrolled horizontally. The titles 
of the various horizontal lines of data also does not scroll, kxjt the data series may t>e scrolled fonward or t>ackward 
55 through time. The month and year assodated with the data are displayed immediately atxyve the working area of the 
screen. 
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PSI Reconciliation 

While working with the data in the temporary P, I and S lines, the user may want to make sure the three lines are 
always consistent Th^ may be accomplished by selecting PSI Reconciliation on the Optk>ns menu (see figure 62). 
5 When selected, a check mark will appear next to this menu choice and the PSI screen will reconcile all data input 
by the user. PSI Reconciliation 170 functk)ns by updating one line of data based on a new value Input into a cfifferent 
line. The user has control over which line gets updated t)y setting the PSI reconciliation order. 

The user sets the PSI recond!iatk>n order by choosing PSI Reconciliation Order from the Optior^ Menu (see figure 
61). This will open the PSI Reconciliation Dialog Box (see figure 62). From this window the user can choose which 
10 line(P, S or 0 ^ updated when the selected line is modified by the user. In the example shown, the I line would be 
updated when the Production line is changed. 

Capacity Checking 

75 While working with the Production, Inventory and Sales figures, the user may wish to check the capacity of the 
existing production resources to determine if the current plan is feasible. This is knom\ as capacity checking. This can 
be accessed by clicking the Check Capacity button on the Options menu group on the main PSI screen. The main 
capacity checking diak)g box will then be displayed (see figure 63). 

The Options tab alkiws tiie user to select the desired plant kx;ation and the feature of interest and pick the existing 

20 lines that may produce the products with the selected featura The user may remove selected products from the list of 
products that he wishes to analyza The user may select the Production resources he wishes to analyze from the Gst of 
available production resources. The user may select the key components of the products that he wishes to analyza The 
user may change the options before performing capacity checking to restrict the scope of the Model Engine 20, and 
after checking capacity fa viewing purposes. 

25 The results tab sfraws (see figure 64) the results of the capacity checking. For all products selected, a production 
plan is dsplayed, arxJ at the top of the screen, whether or not the plan is leasble s indicated. The capacity checking 
may t>e viewed product by product or by product group. 

The production resource tab (see figure 65) is used to show the available capacity for the selected line for two 
months. If this line has enough capacity, it is indicatedatthetopof the screen to be feasit)la The user can also see how 

30 much capacity remains or how much more is needed by looking at the Over and Under lines. 

The Key Components tab (see figure 66) is used to view the irrportant components required to assemble a final 
product arxJ check whether, using the current figures, there is suff ident quantity of these components. If too much pro- 
duction requiring one key component is scheduled and the part will run out tiien the key component is indk;ated as 
infeasibla 

35 The Bill of Material tab (see figure 67) alk]ws tfie user to see which components are used in which products. By 
selecting specif ic components, the user can see wftich products use the components. 

The Alternative Components tab (see figure 68) alk3ws the user to see components that may be sut>stituted for 
other components during production. The user may view the list in two ways. By selecting Product, the user can see the 
corrponents that are used to assemble the product and ariy alternative for the components. By selecting Component. 

40 the user can see spedftocorrponents and arry alternative parts that exist. 

The Resource Requirement tab (see figure 69) alkiws tiie user to see the projected production plan for a selected 
assembly line and product feature typa The user may view this by selecting a line then a product group that may be 
produced on the line or by selecting a product group then a line and viewing the schedule for the selected product 
groups. 

45 

Key Components Selection 

To analyze production of a product the user must work with the components that are used to buikl the product. The 
user does not need to exhaustively analyze all components, but just a sut>set of the components. These are the major 
50 corrponents of the product and are usually referred to as tfie Key Corrponents. Which components are considered key 
may change over time, so the user must have a way of selecting the current key components. This task is performed by 
using the Key Component Selection cfiatog box (see figure 70). 

The Key Components column of the main display area indicates whether the component is a key component All 
key components are also shown in a list at the right of tfie diak)g box. The i^er may change the setting of a component 
55 or multiple components by selecting them and dicking ttie Key Components button to set them to be k^ or Not K^ 
Components to make the corrponents not key. The user may sort tfie corrponents so all k^ corrponents are shown at 
tfie top of the list by dicking the Sort Components button. 

The second colimin of the main display area is a total for a selected range of months The default is for the entire 
year. The user may select a different range by using the mouse to highlight a range of months and dicking the Ordered 
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Based on Months button. TTiis will retotal the cdunvi for the selected range of nionths and change the caption for the 
column to indicate the month range selected. It will also sort the list of components to show the products from greatest 
avaOabilfty ever usage to least availabOity over usage ever the selected time period. 

The many features and advantages of the Invention are apparent from the detailed specification and, thus, it is 
5 intended by the appended claims to cover all such features and advantages of the invention which fall within the true 
spirit and scope of the invention. Further, since nunnerous modifications and changes wiD readily occur to those skilled 
in the art, rt is not desired to limit the invention to the exact construction and operation illustrated and descn'bed, and 
accordingly all suitable modifications and equivalents may be resorted ta failing within the scope of the invention. 

10 

Appendix A 

Database Specifications for Manufacturing Supply Chain 

y5 The following are the specifications of the data tables for the 

manufacturing supply chain. 

Aggregate Production Plan Data 

Data related to the aggregate production plan for the product and resource 
~, identified in the APP header 



j Field Identifier 


Field 
Type 


Description 1 


APPHeaderlD 


Long 


APP Header identifier (see aggregate 1 
production plan Header table) R 


TimePeriod 


Date/Time 


Time period number 1 


1 Si^plyOrderlD 


Text 


Supply order pegged to (if H 
available) H 


I Quantity 


Double 


Number of units of production V 


1 ProposedChange 


Double 


Recommended change in the planned Q 
quantity (to store changes between 8 
regeneration of APPs) 1 



3S 



40 



45 



50 



55 
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Aggregate Production Plan Header 

Header file for defining the Product X Resource X Time resolutions and 



1 

' 1 


values for various aggregate production plans. 


Field Identifier 


Field 
Type 


Description 




APFHeaderlD 


Long 


APP Data Series Identifier 


10 


APPXD 


Text 


Identifier for an aggregate 
production plan 




ResourceResolution 


Text 


Resource Resolution: R- Resource, G- 
Oroup, N-Node 


IS 


Resource ID 


Text 


Resource associated with an 
aggregate production plan 




ProductResolution 


Text 


Product Resolution: P* Product, 6- 
Group 




Product ID 


Text 


Product associated with an aggregate 
production plan 


20 


. TimeResolution 


Text 


D for day; w for i#ee)c; F for bi- 1 
weeJdy; M for monthly; B for bi- H 
monthly; Q for quarterly; and A for H 
annually. 1 




Calendar n> 


Integer 


Pegged to a predefined calendar 1 


25 


DateCreated 


Date/Time 


Date when the aggregate production 
plan was created (based on the time 
resolution) 


30 


ScenarioData 


Boolean 


Yes if it is scenario data. No 1 
otherwise | 


ScenarioCounter 


Byte 


Number of scenarios in which this 1 
header participates || 



Bxidget Data 

Data for budgeted costs and revenues 



Field Identifier 


Field Type 


Description | 


Budge tBeaderlD 


Long 


Budget header identifier 


TimePeriod 


Date /Time 


Time period number 


TargetRevenue 


Doxible 


Target revenue in $ 


BudgetCost 


Double 


Allocated cost in $ 



45 



50 
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Budget Header 

Header file for defining the Product X Resource X Customer X Time 



5 1 


Field Identifier 


Field Type 


Description 1 




Budge tHeaderZD 


Long 


Identifier for the BudgetHeader D 




ProductResolution 


Text 




10 1 


Product ID 


Text 


1 




CustomerResolution 


Text 


Custcmier Resolution: C for Customer, 
0 for Customer Oroup, A for all | 




Customer ID 


Text 


Customer zissociated with the budget 1 


75 1 


ResourceResolution 


Text 


Resoiirce Resolution: R-Resource, G- 
Qroup, H-Mode 




Resource ID 


Text 


Resource associated with the budget 


20 1 


TimeResolution 


Text 


w for week; F for bi-t«ee)ay; M for 
monthly; B for bi-nonthly; Q for 
quarterly; and A for annually 


1 CalendarZO 


Long 


Pegged to a predefined calendar 


1 DateCreated 


Date /Time 


Date of creation for this header 


25 


ScenarioData 


Boolean 


Yes if it is scenario data. No 
otherwise 




j ScenarioCoiinter 


Byte 


Number of scenarios in which this 
header participates 


Calendar 
30 Predefined calendars 


to peg the various data to 




1 Field Identifier 


Field Type 


Description I 




Calendar ID 


Long 


Dnique calendar identifier 


- 


Date 


Date/Time 


Julian Calendar Date 


DayNo 


Double 


unicpie number for a day in the 
calendar year (typically 1 through 
365) 




WeekNo 


Double 


unique msnber for a week in the 
calendar year (typically 1 through 52) 


40 


BiHeekMo 


Double 


Unique number for a bi-week in the 
calendar year (typically 1 through 26) 




i MonthNo 


Double 


nnqiue number for a month in the 
calendar year (typically i through 12) 


45 


1 BiMonthNo 


Double 


Unique number for a bi -month in the 1 
calendar year (typically 1 through 6) 




1 QuarterNo 


Double 


imique nwnber for a quarter in the 
calendar year (typically 1 through 4) 


50 


1 Holiday Indicator 


Boolean 


To indicate whether it is a holiday or 



55 
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Component 



1 Field Identifier | Field Type 


Description 1 


Component ID 


Text 


CooponantlD in the planning BOM from 1 
corporate master (e.g. 3317307) 1 


ConipoiiCTitHaTiw 


Text 


Name of the component 


MinPaOcQuantity 


Double 


Hininum pack quantity 


PhyaicalPaarameter 


Text 


Physical dimensions for the 


GotopCategory 


Text 


S for Off-the-shelf; C for | 
Customized 1 


Packaginglnstruction 


Text 


Special packaging requirements | 



Cooponent Accommodation Katrix 



Field Identifier 


Field Type 


Description | 


Product ID 


Text 


SKD number || 


PrimaryConqponentlD 


Text 


Primary component identifier 1 


AltemativeCoii9>onentID 


Text 


Alternative con^xment identifier 


Quantity 


Text 


l?umber of components ■ of the 
Alternative Component that can 
substitute for one unit of the 
Primary component to product 
ProductID 



Coo^onent Requirement Data 



1 Field Identifier 


Field Type 


Description | 


CoB^ReqHeaderlD 


Long 


Identifier for the conqponent | 
requirement header | 


TimePeriod 


Date/Time 


Time period number 1 


Quantity 


Double 


Number of units during the time period 1 


Proposed Change 


Double 


Proposed Change in required quantity j 
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Cooponent Requirement Reader 

Header file defining the component X Time resolutions and values for 



IS 



40 



various coo^xment req 


uirebent data 


1 Field Identifier 


Field Type 


Description | 


1 ConqpReq^eaderlD 




Component Requirement Header 
Identifier 


1 ConqponentlD 


Text 


Component associated td.th an 
components requirements plan 


BOMID 


Text 


Unique identifier for BOM 1 


DateCreated 


Date /Time 


Date %dien the component requirements 
plan was created (based on the time 
resolution) 


TiroeResolution 


Text 


D for day; W for week; F for bi- 
weekly; H for monthly; B for bi- 
monthly; Q for quarterly; and A for 
annually 1 


Calendar ZD 


Integer 


Pegged to a predefined calendar 1 


AFPID 


Text 


Pegged to an aggregate production plan 1 
(if warranted) I 


Sc6naricl>ata 


Boolean 


Yes if it is scenario data. No 1 
otherwise \ 


1 ScenarioCounter 


Byte 


RUnber of scenarios in idiich this \ 
header participates | 


Component Siipplier 
Data for the supplier 


of cuuipuuents 


Field Identifier 


Field Type 


Description H 


ConpSupplierlD 


Text 


unique identifier for the conq>onent H 
supplier 


S\v)plierMaiDe 


Text 


Name of the component supplier 


PaymentTenns 


Text 


Example: Net-60 


StreetAddress 


Text 


Street Address 


StateZD 


Text 


Name of the State 


Postal Code 


Text 


Postal code 


Country 


Text 


Name of the country 



45 



SO 
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Component SiQ>ply Contract 



5 


Field Identifier 


Field Type 


Description • 




SupplyContractID 


Text 


Identifier for the supply contract 




ContractDate 


Text 


Date of the contract 


10 1 


Noml a 1 LeadTime 


Text 


Negotiated nominal lead time for a 
defined average quantity 




UnitPrice 


Double 


Negotiated unit price of the component 




QtyDiscount 


Double 


Percentage of discount if the quantity | 
is above QtyforDiscount i 


75 


QtyforDiscount 


Double 


Minimum size of the Order to qualify | 
for the quantity discount . | 




MinOrdezQty 


Double 


Minimum quantity that can be ordered 1 
from the sx^lier | 


^ 1 
I 


ronponent 8\qpply Node 

^ta associated irith the CGoqpcment 


supply node 




Field Identifier 


Field Type 


Description R 


25 


CoQ^Siq^lyNode ID 


Text 


unique identifier for the siqyply node 1 
(e.g., CVTCabinetNodel) R 




ConipSiippl ierlD 


Text 


Identifier of the component supplier 1 




AvgSupplyLeadtime 


Double 


Average lead time to stgpply the 1 
components (from the time of order) | 


30 


SupplyContractID 


Text 


ID for the St^ly Contract (See R 
Component Supply Contract Table) U 




PreferredCarrier 


Text 


Preferred transportation carrier for 
shipping (e.g., FEDEX) 


35 


Customer 

Data for individual c 


ustomers 




1 Field Identifier 


Field Type 


Description 


40 


CustomerlD 


Text 


Customer from corporate customer 
master (e.g. BestP) 




ShipToLocation 


Text 


Specific customer location (e.g. DCl) 




DemandNodelD 


Text 


The demand node this customer is 
associated with i 


45 


CustomerHanie 


Text 


Name of the customer 




Address 


Text 


Street address 




1 State 


Text 


Name of the state 




1 PostalCode 


Text 


Postal code (Zipcode for domestic) 1 


50 


II Coimtry 


Text 


Name of the Country I 
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Customer Group 

Data for customer groups 



H Field Identifier 


Field Type 


Description y 


1 CustomerGroupXD 


Text 


Identifier for the customer grotqp 0 


1 CustonterOroupName 


Text 


Descriptive name of customer grot^ 1 
(e.g.. Stereo CTV) 


CuBtonerGroupTag 


Text 


Organizational entity ^iho defined the 
build- criteria for the customer group 
(e.g. Marketing) 


Comment 


Text 




ScenarioGroiq) 


Boolean 


yes if this is scenario group; Ho 
otherwise 


Customer Group 'Definition 

Table that identifies the parent- child relationship between customer groups 
and customers 


1 Field Identifier 


Field Type 


Description | 


1 Cus tome rO roup ID 


Text 


Name of the customer group | 


1 CustomerlD 


Text 


name of the mmber customer (or 1 
customer group) J 
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Customer Orders 

Data for actual cuetomer orders 



5 



IS 



25 



Field Identifier 


Field Type 


Description 


CuatomerOrderXd 


Tex:t 


ID for the actual customer order (e.g. 
pcec type 1 orders) 


LineitemID 


Text 


Line it«n within the order 


CuatomezOrderRefKo 


Text 


Customer's purchase order Identifier 


CustomerlD 


T^Xt 


Customer identified with the order 


H ShlpToLocation 


Text 


snip to xocation zor wne oroer i 


1 ProductID 


Text 


Product associated with the order 


Cal ftndflrTP 


Long 


Pegged to a calendar 


1 xniejcesoxubXoii 




n ^f\r Askv If f oir w^Alt i V far hi.* 
weekly; H for monthly; B for bi* 
monthly; Q for quarterly; and A for 
annually. 


OrderBntryDate 


Date/Time 


Ba^ressed in terns of the ralendar and 
time resolution 


RequestedDate 


Date /Time 


Bxpressed in terms ox tne calendar ana 
time resolution 


DueDate 


Date/Tinke 


Bxpressed in terms of the calendar and 
time resolution 


SbipDate 


Date/Time 


Bxpressed in terms of the calendar and 
time resolution 


1 DellveryDate 


Date/Time 


Bxpressed in texns of the calendar and 
time resolution 


1 Quantity 


Double 


Quantity of the order 1 


H Conments 


Memo 


Such as value added services 1 
associated with the order | 



35 



40 



45 



SO 



Customer Product Resource Relationship Matrix 

Table that identifies the Customers, Product and Resources that have 



1 Field Identifier 


Field Type 


Description 


1 ProductResolution 


Text 


Resoluticm of the product; P for 
product, 6 for product group 


1 ProductID 


Text 


Identifier for the product or product 
group 


1 CustomerResolution 


Text 


Resolution of the customer: C for 
customer, G for customer group 


CustomerlD 


Text 


Identifier for the customer or 
customer grot^ 


DatatypelD 


Text 


POS Data, Top Down Forecast, Bottom Op 
Forecast 


ResourceResolution 


Text 


Resolution of the resource: R for 
resource, 6 for resoujrce group 


1 ResourcelD 


Text 


Identifier for the resource or 
resource group 
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Demand Bistory Data 

Data for the demand hiatory for the product defined in the header 



1 


Field Identifier 


Field Type 


Description 


s 


YVtwyn*^1 wtHffaderTP 




Identifier for a demand history 




TimePeriod 


Date /Tine 


Time period number 


1 


DeraandQty 


Long 


Demand Quantity 


10 

1 
1 


Demand Hiatory Header 

aeadar file defining the Customer . 

trarioua demand hiatoriea 


X Product X Time resolutions & values' for 




Field Identifier 


Field Type 


Description ' 


IS 


DemandHi etHeaderlD 


Long 


Identifier for a demand hiatory header 




ProductReaolution 


Text 


P for product; 0 for Product Qroup; A 
for all products 




Product ID 


Text 


Product associated with demand history 


20 


CuatomerBesolution 


Text 


S for customer ship to; C for 
customer; 0 for customer graap; M for 
market; A for all customers 




Customer ID 


Text 


Customer associated with dmnanrt 
history 


25 


TimeResoIution 


Text 


D for day; W for %mek; P f or bi- 
weeUy; H for monthly; B for bi- 
monthly; Q for quarterly; and A for 
annually. 




Calendar ID 


Integer 


Pegged to a predefined calendar 




DateCreated 


Date/Time 


Date of creation of the header 


30 


ScenariOData 


Boolean 


Yes if it is scenario data. No 
otherwise 




ScenarioCounter 


Byte 


Klumber of scenarios in which this 
header participates 



Demand HOde 

Data associated with the demand node 



40 



\ Field Identifier 


Field Type 


Description 


DeraandNodelD 


Text 


tiaique identifier for the demand node 
(e.g., SBAB5 or a region) from the 
enterprise point of view 


DemandHodeHame 


Text 


Description of dpmand node 


Comment 


Text 





Demand Orientation Data 
45 Data associated with the demand orientation for the product identified in 
the header 



Field Identifier 


Field Type 


Description 


OrientationBeaderlD 


Long 


Orientation Header Identifier 


TimePeriod 


Date /Time 


Date when the order is projected as 
required I 


Quantity 


Double 


Quantity of the orientation | 



55 



119 



EP 0 770 967 A2 



Demand Orientation Header 

Header file defining the Customer X 

for various dwnnnd orientations 



Product X Time resolutions and values 





1 Field Identifier 




Field Type 


Description 




OrientationHeaderlD 


Long 


Orientation Header Identifier 


10 


CustomerResolution 


Text 


S for cus toner ship to; C for 
customer; 0 for customer group; M for 
market; A for all customers 




CustomerlD 


Text 


Customer identified with the place 
keeping order | 




ProductResolution 


Text 


P for product; 0 for product group; A 
for all products 


15 


Product n> 


Text 


Product associated with the 
orientation order 


20 


TiroeResolution 


Text 


D for day; W for week; P for bi- 
%^eekly; M for monthly; B for bi- 
monthly; Q for quarterly; and A for 
annually. 




Calendar ID 


Long 


Pegged to a calendar 1 




DateCreated 


Date/Time 


Date the header was created 


25 


ScenarioData 


Boolean 


Yes if it is scenario data. No 
otherwise 




ScenarioCounter 


Byte 


Number of scenarios in %ifaich this- 
header participates 


Domain 

^ User and domain descri 


ption for var 


ious domains 




Field Identifier 


Field Type 


Description 




DomainXD 


Lon? 




as 


DomainHaroe 


Text 


The name of the domain 1 




DomainOMner 


Text 


The o«mer of the domain | 



Domain Definition 



Field Identifier 


Field Type 


Description 


DomainID 


Lon^ 




ProductResolution 


Text 


P for product; 6 for Product Group; A 
for all products 


Product 


Text 




Cus tomerResolut ion 


Text 


C for customer; G for customer groi^; 
N for market; A for all cwtomers 


Customer 


Text 
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Feature Choices 

The varioua unique values for the different product features -generated on a 
batch basis 



5 



10 



15 



20 



Field Identifier 


Field Type 


Description | 


ProductType 


Text 


The type of the Product that these | 
features belong to 


Feature 


Integer 


Featxure of the Product 


Choice 


Text 


Kame of the Feature possibility 


Forecast Data 

Data associated with 

forecast header 


forecasts for 


the product -customers identified in the 


Field Identifier 


Field Type 


Description 1 


FcstBeaderlD 


Long 


Pegged to the Forecast Header' Table 


TimePeriod 


Date/Time 


Tine period number 


PorecastValue 


Double 


Forecast data value 


PorecastCV 


Double 


Coefficient of variation of forecast 



Forecast Header 

Header file defining the Customer X Product X Time resolutions k values for 
various forecasts 



1 Field Identifier 


Field Type 


Description | 


1 FcstHeaderlD 


Long 


Forecast Header Identifier 1 


30 


ProductResolution 


Text 


P for Product, 6 for Product Group, A 1 
for all Products 




Product ID 


Text 


Product associated with forecast 




CustomerResolution 


Text 


S for Ship- to, C for Customer, O for 
Customer Group, A for all Customers 


35 


CustomerlD 


Text 


Customer associated with forecast 




TimeResolution 


Text 


D for day; W for week; F for bi- 
weekly; H for monthly; B for bi- 
monthly; Q for quarterly; and A for 
annually. 


40 


1 CalendarlD 


Integer 


Pegged to a predefined calendar 




DateCreated 


Date/Time 


Date when the forecast was created 
(based on the time resolution) 




FOrecastType 


Text 


B for bottom-up; T for top-down 


45 


ForecastAssusnptions 




Assumptions associated trith the 
forecast 




PorecastOwner 


Text 


Author of the forecast 


SO 


ScenarioData 


Boolean 


Yes if it is a scenario data; No 
otherwise 


ScenarioCounter 


Byte 


Humber of scenarios in which this 
header participates 
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Freight Rate 

Table that aunmarizeB the various freight ratea 



1 Field Identifier 


Field Type 


Description . | 


1 FreightRateTableZD 


Text 


Preiaht rate table identifier 1 


1 FreightDescription 


Text 


Descriotion of the rate table 1 


MaxNeight 


Double 


Maximum weight limit (e.g. truck 1 
caDacitv) 1 


HaxCute 


Double 


Maximum volime li.nit 1 


WeightCategory 


Text 


e.o. 0-1001b« 100-5001b. etc. fl 


HileageCategory 


Text 


e.g. less than 100 miles, less than 
500 miles, etc. 


nxnxniuniciiarge 


Double 


Minimum charge associated With a trip 


StdCoat 


Double 


e.ci. oer faundred weioht chAroA for 
LTL and $/mile for TL 


BcononyCost 


Double 


e.g. for fedex economy rate 


PremiuroCost 


Double 


e.g. for fedex next day service 


Inventory Data 
Inventory data for it 


ema (products 


or conqpionents) identified in the header 


Field Identifier 


Field Type 


Description 


InventoryHeaderlD 


Long 


Inventory Data Series Identifier 


TimePeriod 


Date/Time 


Time period number 


j OnBandlnventory 


Double 


On-hand available inventory for D 
allocation | 


1 QnOrderlnventory 


Double 


On-order inventory 1 


1 BackOrderlnventory 


Double 


Back-ordered inventory 


InTranait 


Double 


In- transit quantity 


Reaervedlnventory 


Double 


Reserved inventory on-hand but 
available for allocation only in case 
of emergency 
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Inventory He&der 

Header file defining the item (Product or Con^ionent) X Time fc and values 
£or various inventory data 



Field Identifier 


Field Type 


Description 


InventoryHeaderlD 


Long 


Inventory Data Series Identifier 


InventorySodeH) 


Text 


Identifier for an inventory logical 
warehouse 


InventoryOontrolID 


Text 


Identifier for inventory control 
parameters 


ItemTD 


Text 


Product Item ID 


ItemResolution 


Text 


Item Resolution: C for Component, P 
for Product, 0 for Product Oro\q> and A 
for All 


TimeResolution 


Text 

• 


D for day; H for week; P for bi- 
weejuy ; n kwe^ iiw,»i<fii iy , o £0£^ bjl ~ 

monthly; Q for quarterly;, and A for 
annually. 


CalendarlD 


Integer 


Pegged to a predefined calendar 


MinlnventoryLevel 


Double 


Minimum inventory level for the itra 


HaxInventoryLevel 


Double 


Maximum inventory level for the item 


DateCreated 


Date/Time 


Date the inventory header was created 


ScenarioData 


Boolean 


Yes if it is scenario data. No 
otherwise 


ScenarioCounter 


Byte 


number of scenarios in i^ch this 
header participates 


Inventory Hode 

Data associated with the inventory node 


1 Field Identifier 


Field Type 


Description 


InventoryModelD 


Text 


Unique identifier for the inventory 
node (e.g., ArdenNarehouseS) 


PacilitylD 


Text 


Physical Facility identifier 


inventoryCategory 


Text 


Component or PG- Enterprise 


i InventoryBchelon 


Double 


1 or 2 


InventoryNOdeName 


Text 


Name for the inventory node 


ServiceLevel 


Double 


Service level for the inventory node 


Address 


Text 


Address for the inventory node 


StorageCapacity 


Double 


Physical storage capacity of the 
inventory node (in c\ibic feet for 
example) 
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Inventory Parametera 

Data for the in;vent6ry control parametera 



1 Field Identifier | Field Type 


Description | 


InventoryCQntrolIB . 


Text 


Identifier for inventory control 
parameters: Assume inventory 
.planning • inventory control 


SafetyStoc)cPactor 


Double 


Safety stock factor 


TargetServlceX<evel 


Double 


Target service, level 


PolicyType 


Text 


Policy type: 8S,Min/Max,QR,etc. 


MinlnventoryPactor 


Double 


M4n4fmim iflvtrant^irv ^ACfcor (e.a. . in 

terms of weelcs of sales) 


MaxInventoryFactor 


Double 


Haximum inventory factory (e.g.« 
in terms of weeks of sales) 


MinOrderQtyPactor 


Double 


H^niimmi ordsT (jusntity factor 


CarryChargeFaetor 


Double 


Carrying cost factor 


OrderCtaargeFactor 


Double 


Ordering cost factor 


inventoryClasa 


Text 


Inventory classification 


Replenishment 
Frequency 


Double 


Frequency of replenishment w.r.t. 
the time resolution in the header 



Market Data 



Data for the market defined in the 


leader 


1 Field Identifier 


Field Type 


Description 1 


HarketHeaderlD 


Long 


ID for market header (see Market 
Header table) 


TimePeriod 


Date /Time 


Time period 


Mar)cetShare 


Double 


Percentage of share held by the 
company 


1 ConsumerDemauid 


Double 


Total demand quantity 


I AverageSellingPrice 


Currency 


Average Onit Price of the product 


B DemandForecast 


Double 


Forecasted drmsnd 
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Market Header 

Header for defining the market (Product. X Customer reeolutions) and values 



Fiela laentl£xer 


Field Type 


I>e8cription 


MarketBeaderZD 


Long 


Identifier for the market header 


MarketDeflnltionZD 


Text 


unique identifier for a market (e.g., 
PTV-S) 


MarketHame 


Text 


Market Description (e.g. Projection TV 
in Selling floor) 


1 DataScope 


Text 


Suitable tag: Brand name (e.g., Sony) 
or industry-wide 


1 DataSourcelO 


Text 


Source of market data (e.g, NIEIiSBH) 


1 TlmeResolutlon 


Text 


D for day; tf for week; F for bi- 
weekly; M for monthly; B for bi- 

annually. 


9 Calendar XD 


Integer 


Pegged to a predefined calendar 


ir& wuuc b ciCBOX u b jk otu 


XCJfcW 


products 


Product IP 


Text 


Identifier for the oroducfc 


CustoinerResolution 


Text 


C-Cuatomer, CO-Customer Group , A- All 


CustomerlD 


Text 


Identifier for the customer 


DateCreated 


Date/Time 


Date the he2uler was created 


ScenarioData 


Boolean 


Yes if it is scenario data; Ho 
otherwise 


ScenarioCounter 


Byte 


Nlunber of scenarios in which this | 
header participates | 


Material Z>elivery Schedule Data 

Material Delivery Schedule for the Conponent identified in the header 


Field Identifier 


Field Type 


Description | 


1 MDSHeaderXD 


Long 


Identifier for the Material Delivery 1 
Schedule Header 1 


1 DeliveryDate 


Date/Time 


Material Delivery Date 1 


1 Quantity 


Double 


number of units of material delivery \ 
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Hater lal Delivery Schedule Header 

Header file defining the Component X Sv^ipXier X Time resolutions 4 values 
for various nateirial delivery schedules ; 



5 


Field Identifier 


Field Type 


Description 




MDSBeaderZD 


LOBQ 


Identifier for the Material Delivery 
Schedule Reader 




OonponentSvQpplyBod 
eXD 


Text 


Identifier for ccunponqnt supply node 


10 


Supplier ID 


Text 


Supplier associated with a Material 
Deliverv Schedule* 


15 


TimeSesolutioQ 


Text 


D for day; W for week; F for bi- 
weekly; N fox monthly; B for bi- 
monthly; Q for quarterly; and A for 
annually. 


Calendar ID 


Integer 


Pegged to a predefined calendar 




DateCreated 


Date/Time 


Date idisn a Material Delivery Schedule 
was created (based on consistent time . 
units) 


20 


ScenarioData 


Boolean 


Tes if it is scenario data, lio 
otherwise 




ScenarioCounter 


Byte 


Nunber of scenarios in which this 
header participates 


25 


DiMnnHng ATM 

loploded Bill of Material used for Planning 




Field Identifier 


Field Type 


Description 




BOMID 


Text 


unique identifier for the planning BOM 
(defined external to the DSS database) 


30 


Component ID 


Text 


unique component identifier 




Product ID 


Text 


SKU number 




Quantity 


Double 


Number of compoTients used in SKU 



35 POS Data 

Point of Sale data for the customer -products identified in the header 





Field Identifier 


Field Type 


Description 




POSBeaderlD 


Long 


POS Header Identifier 


40 


TimePeriod 


Date /Time 


Timer period number (beginning of 
the time period) 




SellThrough 


Double 


Sale to end user 




Shipments 


Double 


Shipments from the customer DC to 
the stores 


45 


Receipts 


Double 


Shipments from the vendor (e.g. 
pcec) to the customer dc 




DClnventoryStatus 


Double 


Qnhand inventory at the ship to 
location (customer dc> 


50 


Store InventoryStatus 


Double 


Aggregate onhand inventory of stores 
served by the customer ship to 
location (e.g. dc) 




StoresOnOrderOty 


Double 


On order quantity from the stores to 
the customer dc 
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POS Header 
Header file defining 
various POS Data 



the Cuatomer X Product X Tine resolutions & values for 



10 



15 



20 



25 



30 



35 



40 



45 



50 



1 Field Identifier 


94^1/1 Till !■ 

rxexQ Type 


■ cnpuxon 


POSHeaderZD 


Long 


Identifier for the Point of Sales 
Header 


CustomerResolution 


Text 


Custoner Resolution: S for Customer 
Shipto, C for Customer, O for Customer 
Groi^, A for all 


Customer ID 


Text 


Should be a valid customer group or a 
null set (e.g.« Selling floor) 


1 ProductResolution 


Text 


Product Resolution: P for Product. G 
for Product Group, A for all 


1 ProductID 


Text 


Product associated with the POS Data 


1 TiraeResolution 


Text 


D for day; w for veek; F for bi- 
weekly; M for monthly; B for bi- 
monthly; Q for quarterly; and A for 
annually. 


II caienqarm 






1 DateCreated 


Date/Time 


Date the POS Header was created or 
modified 


y ScenariOData 

1 


Boolean 


Yes if it is scenario data; No 
otherwise 


1 ScenarioCounter 


Byte 


number of scenarios in which this 
header participates 


Product 

Data for end products 






Field Identifier 


Field Type 


Description 






RR1330H) 


ProductHame 


Text 


Name of the Product 


Product Category 


Text 


Product Category 


Featurel 


Text 


Exanple : Brand 












Bamnole- Xliidio* M-Mono. S-Stereo. P- 
Prologicp D-Dolby Prologic 


Feature4 


Text 


Example: Subtype 


Features 


Text 


Example: Cabinet type 


Features 


Text 


Bxanple: Chassis type 


ProductDescription 


Text 


Description of the product 


SKUSize 


Double 


Number of product units in a SEXS 


1 PtayaicalDiinensions 


Text 


Height X Depth X Width 


1 Weight 


Double 


Weight of the SKD I 
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Product Features 

The feature list of the products 



20 



Field Identifier 


Field Type 


Description . | 


ProductCategory 


Text 


Product Category | 


FeatureHUtnber 


IjOpg 


Feature Field Huniber | 


FeatureName 


Text 


Feature Bame Description | 


Product Groiq> 

Data for product gxtn^ 


ps 


Field Identifier 


Field Type 


Description 


ProductGroupID 


Text 


Identifier for the product . group 


ProductGroupName 


Text 


Descriptive nams of product group 
(e.g. 19Stereo) 


ProductOroi^Tag 


Text 


Organisational entity «dso defined the 
build criteria for the product grotqp 
(e.g. Marketing) 


ScenarioGrou|> 


Boolean 


Yes if this is scenario gro\q>; No 
otherwise 



25 



Product Group Definition 

Table that identifies the parent-child relationahip between product 
and products 



30 



35 



Field Identifier 


Field Type 


Description 


ProductGroupParentID 


Text 


Identifier for the product group 
that is the parent 


ProductGroupChlldID 


Text 


Identifier for the product group or 
product that is the child 


Production Accomroodatic 
Table that identifies < 
various products 


m Matrix 
iltemative pi 


roduction resources for producing 


1 Field Identifier 


Field Type 


Description 1 


Product ID 


Text 


Identifier for the Product 


PrimaryResourcelD 


Text 


Identifier for the Primary Production 
Resource 


AltemativeResource 
ID 


Text 


Identifier for the Alternative 
Production Resource 


Quantity 


Double 


Nuihber of units of Alternative 
Resource that can substitute for 
Primary Resource to Product 
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Production Capacity Data 

Production Capacity Data of the production resource identified in the 
header 



5 


Field Identifier 


Field Type 


Description 




Product i cnCapacity 
Header ID 


Long 


Production Capacity Header ID (See 
Production Capacity Header Table) 


10 


TimePeriod 


Date/Time 


Timer period number 




NoShifts 


Double 


ITumber of planned shifts during the 
time period 




LoadingPactor 


Double 


Planned loading rate (e.g. % 1 
utilization) 1 


IS 


YieldPactor 


Double 


Target yield values 1 




DowntimeFactor 


Double 


Projected downtime 












CapacityAvailable 


Double 


Capacity available 


20 

] 
1 

i 


Production Capacity B 
Seeder file defining 
Cor varioua Productio 


eader 

the Productio 
n Capacity Da 


a Resource & Time resolutions ft values 
ta 


25 


Field Identifier 


Field Type 


Description | 




derlD 




Produntilfin Caned H^adftr TD 1 


30 


ReaourceReeolution 


Text 


N for Production node, RO for 1 
Production Group and R for Production | 




Kefloiirce ID 


Text 


ResoiuTce (Resource. Oroixo or Mode) 1 
associated with an aggregate I 
production plan H 


35 


CanacitvOnit 


Text 


SicainDXe mimibAr of oroducti^on hours . S 
shifts, etc. (related to the time 1 
resolution) H 


40 


TimeResolution 


Text 


D for day; if for weeic; F for hi- 1 
wee)cly; M for monthly; B for bi- | 
monthly; Q for quarterly; and A for 1 




CalendarlD 


Integer 


Pegged to a predefined calendar | 




DateCreated 


Date/Tine 


Date «dien the aggregate production 
plan was created (based on the time 
resolution) 


45 


ScenarioData 


Boolean 


Yes if it is scenario data, HO 
otherwise 




ScenarioCounter 


Byte 


Nuflober of scenarios in tdiich this 
header participates 



50 
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Production Matrix 

Aggregate matrix defining the production rates for Product X Resource 
cocnbinationa 



Field Identifier 


Field Type 


Description I 


ProductMatrixID 


Text 


Identifier for the production matrix 1 


ResourceResolution 


Text 


Resource resolution loentxtier 


ResourcelD 


Text 


Tmique identifier for the production 
resource (e.g., FAIO) 


proauctResoxucxon 


xexc 


for Product, G for Product Group 


Product ID 


Text 


unique identifier for input product 
(group) ^ 


1 YieldRate 


Double 


Actual yield rate for the product on 
the resource 


TimeResolution 


Text 


D for day; W for week; F for hi- 
weeUy; M for monthly; B for bi- 
monthly; Q for quarterly; and A for 
annually. 


ProcessTime 


DouDle 


Actual time ox proouction 


SetupMatrixID 


Text 


Identifier cor tne setup time roacrxx h 


Production Node 

Data for the producti 


on node 




1 Field Identifier 


Field Type 


Description I 


1 ProductionNodelD 


Text 


Uhique identifier for the production R 
node (e.g., PTVNodel) 


1 Product ionNodeName 


Text 


Name of the production node H 


1 Connient 


Text 




Production Requirements Data 

Production Requirements Data for the product identified in the header 


[ Field Identifier 


Field Typo 


Description I 


ProdReqHeaderip 


Long 


Production Requirement Header 1 
identifier (see Production t 
Requironents Data Header table) 1 


TimePeriod 


Date/Time 


Time period number 1 


Quantity 


Double 


Number of units of production 


ProposedChange 


Double 


Proposed change with respect to the 
quantity 1 
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Productlra Requlrerouxts Header 

Header file def^"<"j the Product X Time resolutions k values for various 
Product Requirements data 



5 


Field Identifier 


Field Type 


Description I 




ProdRe^eaderlD 




Production Requironent Header | 
Identifier 1 


10 




Text 


Identifier for an aggregate production 1 
plan 1 




ProductResolution 


Text 


Product Resolution: P-Prodct, Q-Group 1 




Product ID 


Text 


Product associated with the production 
requirements plan 


IS 


TimeResolution 


Text 


D for day; W for week; F for bi- 
weekly; M for monthly; B for bi- 
monthly; Q for quarterly; and A for 

Mnmixlly, 






Integer 


Pegged to a predefined calendar 


20 


DateCreated 


Date/Time 


Date when the production requirements 
pXan was creacea loasea on me cime 
resolution) 




ScenarioData 


Booleam 


Yes if it is scenario data, Ko 
otherwise 


25 


ScenarioCounter 


Byte 


Number of scenarios in which this 
header participates 


30 


Promotional Data 
Data related to past 


and future pr 


emotions for Products & Customers in the 




Field Identifier 


Field Type 


Description I 




Promo t ionHeader ID 


Long 


Promotion Header Identifier 1 


35 


TiroePeriod 


Date/Time 


Timer period number (beginning of the 
time period) 




PromotionDuration 


Double 


Time duration for the promotion 




Pre -evaluationQty 


Text 


Estimate before the promotion for the 
sales qty due to the promotion 


40 


1 Post-evaluationQty 


Text 


Estimate after the promotion for the 
sales qty due to the promotion 



45 



50 
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Proootion Header 

Header file defining the Product X Customer X Time reeolutions & values for 
various Promotion data 



5 



20 



30 



40 



50 



\ Field Identifier | Pield Type 


Description | 


PromotionHeaderlD . 


Lon^ 


Identifier for the Promotion Header 1 


CustomerResolution 


Text 


Customer Resolution: S for Customer 
Shipto, C for Customer » 0 for Customer 
Group, A for all 


Customer ID 


Long 


Should be a valid customer grox^ or a 1 
null set (e.Q.. Sellina floor) H 


ProductResolution 

1 


Text 


Product Resolution: P for Product, 6 1 
for Product QronxD. A for all 


Product ID 


Text 


Product associated with the promotion 
Data 


TimeResolution 


Text 


D for day; W for week; F for bi- 
monthly; Q for quarterly; and A for 

AlUlUfil J» m 


Calendar ID 



Text 


Pegged to a specific calendar 


Promo t ionType 


Text 


R for Retailer; P for PCBC; C for 
ccuupec 1 cor 


Proroot ionClass 


Text 


* ^ W J> ^ABOO vAabWV 

Reductions) 


Pr omot ion In tens i ty 


Double 


Intensity of the promotion (low, 
medium, high) 


ProrootionShapelD 


Long 




DateCreated 


Date/Time 




Date of creation of the Promotion H 
Header H 


H ScenarioData 


Boolean 


1 


1 ScenarioCounter 


Byte 




Resource 

Data related to production resource 


1 Pield Identifier 


Field Type 


Description 


ResourcelD 


Text 


Qnique identifier for a production 
resource (e.g. , FAIG) 


ResourceName 


Text 


Descriptive name 


1 ResourceGrot^ID 


Text 


Production gro\q> this resource belongs 
to 


1 NaxLineRate 


Double 


Maximum line rate 


1 NoWorkstations 


Double 


Number of wor)cstations | 


1 MaxBuf fers 


Double 


Maximum number of buffers | 
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Resource Group 

Data related to production resource 



15 



Field Identifier | Field Type 


Description 1 


SesourceGrouDlD 


Text 


Unique identifier for the production 1 
group (e.g., Plaht4} 


ResourceGroiQ^aioe 


Text 


Descriptive name 


ProductionHodeXD 


Text 


Production node this group belongs to 


Attributel 


Text 


Attrilmte (e.g., Category, Location) 


Attribute2 


Text 


Attribute (e.g.. Category, Location) 1 


Attributes 


Text 


Attribute (e.g.. Category, Location) 1 


ScenarioGroi^ 


Boolean 


Yes if this is scenario group; No D 
otherwise | 



20 



25 



Resource Group Definition 

Table that defines the parent -child relationship of the production resource 



Field Identifier 


Field Type 


Description | 


ResourceGroi^ParentU) 


Text 


Identifier for the resource grou^ || 
that is the parent U 


1 Resource6roiq>ChildID 


Text 


Identifier for the resource group | 
or product that is the child H 



Sales Requirements Data 

Sales Requirroents data for the product identified in the header 



Field Identifier 


Field Type 


Description | 


SalesReqHeaderlD 


Long 


BeaderlD pegged to the Sales 1 
Requirement Header table 1 


TimePeriod 


Date/Time 


Time Period pegged to the time 
resolution in the Sales requirements 
header table 


Quantity 


Double 


Quantity required 



45 
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Sales Requirements Header 

Header file definizicr the Product X Time resoXutioni & values for the sales 
requir«nent8 data 



5 



10 



IS 



20 





Tim* 


wescrxpc xon 


SalesRec(HeaderZD 


Long 


Header ZD oC the sales requirements 


ProductResoXution 


Text 


Production Resolution: P-Piroduct, 
PO-Product Qravp, Ai^AXl 


Product ZD 


Text 


Product ZD 


Ti.meRe8oluti.mi 


Text 


Monthly, Q-Quarterly, Y-Yearly 


Calendar ZD 


Long 


Calendar ZD 


DateCreated 


Date/Time 


Date of creation of the sales 
requirements 


ScenarloData 


Boolean 


Yes if it is scenario data. No 

otherwise 


ScenarioCounter 


Byte 


Number of scenarios in ^diich this 
header participates 



Scenario 

Scenario description and user information 



25 



35 



40 



45 



\ Field Identifier 


Field Type 


Description 


ScenarioZD 


Long 




ScenariOName 


Text 




User 


Text 




Description 


Memo 




DateCreated 


Date/Time 




DateUpdated 


Date/Time 




Scenario Data Compatl 
Table that specifies 
pockets on each form 


bility 

what data hea 
for each fram 


ders can be loaded into each of the data 
e 


Field Identifier 


Field Type 


Description | 


Frame 


Text 


Frame Name | 


Form 


Integer 


Form Number | 


Pocket 


Znteger 


Pocket Number | 


TableName 


Text 


Table name for the (Frame, Form, 1 
Pocket) triple | 
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10 



15 



20 



25 



30 



35 



40 



45 



SO 



Scenario Definition 

The table that contains the header ids of the various data that exists in 



each pocket, in each form in each frame for different scenarios 


Field Identifier 


Field Type 


Description | 


ScenarioID 


Long 




Frame 


Text 




rorm 


Integer 




Pocket 


Integer 




ReaderlD 


liong 




DateCreated 


Date/Time 




DateU)pdated 


Date/Time 




Setiq> Matrix 
Aggregate matrix defl 
changeovers 


oing the sequence -dependent 8et\q> times- for product 


rxexu xoenc x r xer 


Field Type 


Description . | 


SetupMatrixID 


Text 


Identifier for the Setup Matrix 1 


PrevProductZD 


Text 


Identifier of the product that has B 
just finished processing | 


1 NextProductID 


Text 


Identifier of the product to be set-up B 
on the resource 1 


TimeResolution 


Text 


D for day; H for week; F for bi- 1 
weekly; M for monthly; B for bi- 1 
monthly; Q for quarterly; and A for H 
annually. fl 


SetupTime 


Double 


Actual time to set up fl 


Supply Chain Itetwork 
SuruCCurax oaca specx 


fying the sup 


ply chain net%«ork 


1 Field Identifier 


Field Type 


Description a^"""^ 


1 LinkID 


Text 


S\CTly chain network link icientif ier 


1 FronNodelD 


Text 


A node ID from any of the three node 
classes: component sxqpply, production 
inventory 


ToNodelD 


Text 


A node ID from any of the three node 
classes: producti<m, inventory, demand 


LinkCapacity 


Double 


Capacity of the link 


1 TransportljeadTime 


Double 


Transport Lead time associated with 
the link 


1 Distance 


Double 


Transportation distance 


1 LinkXndicator 


Boolean 


Yes if it is currently active and in 
use and No otherwise | 



55 



135 



EP0770 967A2 



Supply Order Data 

Data for tha supply orders identified in the headiar 



5 


\ Field Identifier | 


Field Type | 


Description | 


1 SupplyOrderHaaderlD 




Prodiu:tion or supply order (e.g. pcec 
type 4 orders) 


10 


OrderDate 


Date/Time 


Date of creation expressed with 
respect to calendar 




OrientationDatalD 


Text 


Orientation order associated with 
simply order 




DueDate 


Date/Time 


Date the sxqpply order is due 


IS 


Quantity 


Double 


Quantity of the supply order | 


S\qpply Order Header 
Header file defining t 
supply orders 


he Product X 


Customer X Time resolutions 6 values for 


20 


1 Field Identifier 


Field Type 


Description 




Sui^lyOrdei^eaderlD 


Long 


Production or. siqiply order (e.g. pcec 
type 4 orders) 


25 


Cus t omerResolut ion 


Text 


S for customer ship to; C for 
customer; 0 for customer grotqp; M for 
market; A for all customers 




CustomerlD 


Text 


Customer identified with the place 
keeping order 


30 


ProductResolu t ion 


Text 


P for product; 0 for product- group; A 
for all products 




Product ID 


Text 


Product associated trith the supply 
order 


35 


TimeResolution 


Text 


D for day; H for week; F for bi- 
weekly; M for monthly; B for bi- 
monthly; Q for quarterly; and A for 
annually. 




1 CalendarlD 


Long 


Pegged to a calendar 


40 


1 DateCreated 


Date /Time 


Date the Siqpply Order Header was 
created/modified 


1 ScenarioData 


Boolean 


Yes if it is scenario data, 190 

"ii" **r-w W ^ O w 




1 ScenarioCounter 


Byte 


Number of scenarios in ^^ch this 
header |>articipate8 


45 


Temporary Product Z»i8t 
System table that cont 


,ains a tenpox 


-ary product list 




1 Field Identifier 


Field Type 


Description | 


50 


H ProductXD 


Text 
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VMR Contract 

^t^^ssociate^ri^^iVendto^tena^ 



Field Identifier 


Field Type 


Description | 


VMROontractID 


Text 


Identifier for the VMR Contract 1 


Con.tirii.etCAtA 


Date/TloM 




BscDlrftt lonDftt e 


Date/Tinw 




PaymentTems 


Text 


Bxanple: Het-60, Het-30 


ProductResolutlon 


Text 


Product Resolution: P for Product, 6 
for Product Group, A for all 


PrcxSuctZD 


Text 


Product associated with the VMR 


TargetPillRate 


Double 


Fill rate promised in the VMR 
contract 


H TuznAroundTlme 


Double 


Nominal turnaround time 


KlnlnventoryFactor 


Double 


Minimum inventory factor agreed in 
the VMR contract 


MaxInventoryFactor 


Double 


Maximum inventory factor agreed in 
the VMR contract 


OrderRevislonFactor 


Double 


Customer's rights to revise order 


VMR Data 

Data associated with 
identified in the hea 


Vendor Managed Replenishment for the customers 
der 


Field Identifier 


Field Type 


Description 


VKRHeaderlD 


Long 


VMR Header Identifier 


OrderDate 


Date /Time 


Date trtxen the VMR order data was 
entered 


1 PurchaseOrderlD 


Text 


Customer purchase order reference 


1 OrderStatus 


Text 


A for allocated; B for baclcordered; 


OrderQty 


Double 


Quantity associated with the order 


CuittDel IveryQty 


Double 


Quantity delivered against the order 
(cumulative measure) 


DueDate 


Date/Time 


Date when the order is planned to be 
delivered at the customer site 


DeliveredDate 


Date/Time 


Date ^fban the order ma actually 
received at the customer site 


ShipDate 


Date /Time 


Date tdien the order is planned to be 
shipped 


LastShipmentDate 


Date/Time 


Date of the . latest shipment - made to 
fulfill an order 


ShipCarrier 


Date/Time 


The carrier used in delivering the 
order (to keep track of the intransit 
inventory) | 


xankID 


Text 


Pegged to a defined supply chain linlc n 
in the supply chain network table 1 


FreightRateTablelD 


Text 


Based on transportation mode U 
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VMR Header 

Header file defining the Product X Customer X Time resolutions & vales for 
VNR 



5 



15 



20 



30 



Field Identifier 


Field Type 


Description 


VMRBeaderZD 


Long 


VMR Header Identifier 


CustomerResolution 


Text 


Customer Resolution: S for Customer 
Shipto; C for Customer; 0 for Customer 
Qxo\xp, A for all 


1 CustocnerlD 


Text 


Should be a valid customer group or a 
null set (e.g.. Selling floor) 


1 ProductResolution 


Text 


Product Resolution: P for Product G 
for Product Group, A for all 


1 ProductID 


Text 


Product covered by the VMR contract 


TimeResolut ion 


Text 


D for davr If for weelc; F for bi- 
weekly; M for monthly; B for bi- 
monthly; Q for quarterly; and A for 


Calendar IP 


Integer 


Pegged to a predefined calendar 


InventoryControl ID 


Text 


Pegged to inventory control parameters 
ID 


VMRContractID 


Text 


Pegged to the VMR Contract table 


DateCreated 


Date/Time 


Date the VHR Header was 
created/modified 


ScenarioData 


Boolean 


Yes if it is scenario data, No 
otherwise 


ScenarioCounter 


Byte 


Number of scenarios in which this | 
header participates | 
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j^pendlx B 

Datsibase Specifications for Equipment Repair Supply Chain 
The following are the specif icat ions of the data tables for the equipnent 
repair supply chain. 



Bquipotent 

Information to classify equipment into groups. This information is 
relevant to identify reliability characteristics of equipment parts. 



Field Identifier 


Field Description 


A^|WnCI lit* 


Dtiiaufi identifier for ^•h* ecminDent 


BquipnsntLocation 


Location of the equipment 


InspectionLocation 


Location irtiere the equipment is 
inspected/maintained 


DateofMfg 


Tear of manufacture of equipoMnt 


RunningRours 


Total Cumulative running hours so far 


Region 


Region of reconnaissance associated with the 1 
equipment 1 


1 Characteristic 
1 (Identify) 


Other critical characteristic, e.g., total running 1 
time 1 


1 etc. 




Repairable Item and 
Conponent 


Conponent Information 


Field Identifier 


Field Description 


ComponentlD 


Component ID in the BOK 


CoaponentHaine 


Same of the component 


11 MinPackQuantity 


Minimum pack quantity 


0 PhysicalParameter 


Physical dimensions for the conponent 1 


1 CompCategory 


S for Off-the-shelf; C for Customized 1 


B Packaginglnstruct 
1 ion 


Special packaging requirements 1 


Engineering Bill of Material that describes the product structure from 
equipment to repair items to components . 


1 Field Identifier 


Field Description 


BOMID 


Unique identifier for the engineering BOM 


ParentType 


Type of the parent: Bquipnent /Repair Item/Component 


Parentm 


Identifier of the parent (BquipmentID or RepairltemID 
or CongponentlD) 


ChildType 


Type of the child (Repair Item/Component) 


ChildID 


mique identifier for the child (RepairltemID or 
Conponent n» 


Quantity 


Number of components used in parent I 
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Repairable Item 



10 



1 Field Identifier 


Field Description 


RepairltemID 


Onique identifier of the repair item 


RepairltemWame 


Bane/Descriptioa of the repair item 


PhysicalDiroensiona 


Height Z Depth X Width 


Height 


Height of the SXn 



Component St^lier 



15 



20 



25 



Field Identifier 


Field Description 


CompSxtpplierlD 




SupplierName 


Name of the component supplier 


PaymentTerms 


Bxan^le: Het-60 


StreetAddress 


Street Address 


StatelD 


Heme of the State 


PostalCode 


Postal code 


Coimtry 


Itame of the country 



30 



35 



40 



45 



Supply Information 
Repair Time Matrix 

Aggregate matrix defining the repair rates for Repair Item X Repair 
Resource conbinationa 



Field Identifier 


Field Description \ 


RepairMatrixID 


Identifier for the repair matrix | 


ResourceResolution 


Resource resolution identifier | 


ResourcelD 


Uhique identifier for the repair resource 


RepairltemID 


unique identifier for the repair item 


TimeResolut ion 


D for day; W for week; F for bi-wee)cly; H for 
monthly; B for bi-monthly; Q for quarterly; and A 
for annually. 


ProcessTime 


Mean time to repair 


SetupMatrixID 


Identifier for the setup time matrix \ 
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Repair Settq> Matrix 

Aggregate matrix def ining the sequence dependent setup times for repair 
item changeovers 



Field Identifier 


9iald D^Jtc*r4n^4nn * H 




AOgPfcjL I xer Eor cne aewup nacrxx | 


PrevProductZD 


Identifier of the repair item that has just been . 1 
repaired | 


Hext Product ID 
— — — — 


Identifier of the repair item that needs to be 1 
repaired | 


TimeResolution 


D for day; H for week; F for bi-weekly; M for 
monthly; B for bi -monthly; Q for quarterly; and A for 
annually . 


SetYqyTime 


Actual time to settip 



Repair Ca^city Header 

He ad er file defining the Repair Resource X Time resolutions L values for 



Field Identifier 


Field Description 1 


RepairCapacityHeader 


Repair Capacity Reader ID 


ResourceResolution 


Resource Group or Resource 


ResourcelD 


Resource ID 


CapacityUnit 


Example, number of production hours, shifts, 
etc. (related to the time resolution) 


TimeResolution 


D for day; H for %#eek; F for bi-ifeekly; M for 1 
monthly; B for bi-monthly; Q for quarterly; and 1 
A for ann\ially. n 


Calendar ID 


Pegged to a predefined calendar | 


DateCreated 


Date when the aggregate repair plan was created 1 
(based on the time resolution) f 



Repair Capacity Data 



of the repair resource identified in the header 



r Field Identifier 


Field Description 


RepairCi^acityData 

ID 


Repair Capacity Data ID 


TimePeriod 


Time period number 


RepairCapacityHead 
erID 


Repair Ca^city Header ID (See Repair Capacity 1 
Header Table) H 


NOShifts 


Number of planned shifts during the time period 


IioadingFactor 


Planned loading rate (e.g. % utilization) 


DowntimeFactor 


Projected downtime 


CapacityRequired 


Capacity required 


CapacityAvailable 


Capacity available 
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Repair Bstination Header 

Header file defining the Item X Time resolutiona fc values for various 
Repair Batitnation data 



Field Identifier 


Field Description 1 


RepairBstHeaderlD 


Repair Estimation Header Identifier 


ARPZD 


Identifier for an aggregate repair plan 


ItemZD 


Item associated with the production requirraents 
plan 


TimeResolut ion 


D for day; W for week; F for bi-wee)cly; M for 
fMsnthlv; B for hi -monthly; Q for ouarterly; and A 
for annually. 


Calendar ID 


Pegged to a predefined calendar 


DateCreated 


Date trtien the Repair Estimation plan was created 
(based on the time resolution) 


Repair Estimation Di 
Repair Estimation di 


ita 

lui xor fcnc repair ib>dii xucsu&ixacu * h ucaw^ 


Field Identifier 


Field Description 


RepairEstOatalD 


Repair Estimation Data ID 


TimePeriod 


Time period number 


RepairEstHeaderlD 


Repair Estimation Header Identifier 


1 Quantity 


Number of units of production 


H ProposedChange 


Proposed change with respect to the quantity 



35 



40 



45 



50 



Aggregate Repair Plan Header 

header file defining the Repair Item X Resource X Time resolutions values 
foj^arlou^rggregat^Repai^^l^ 



Field Identifier 



RepairPlanHeaderlD 



Repair ID 



ResourceResolution 



ResourcelD 



RepairltemResolutlon 



RepairltemID 



TimeResolution 



CalendarlD 



DateCreated 



Field Description 



Repair Plan Data Series Identifier 



Identifier for an aggregate repair plan 



Resource Resolution; R-Resource^ G-Qroiq>, H-HOde 



Resource associated with the repair plan 



Repair Item Resolution; P-Repair It«n, Q-Groxq> 



Repair Item associated %d.th the repair plan 



D for day; W for week; F for bi-«#eekly; M for 
monthly; B for bi-monthly; Q for quarterly; and A 
for annually. 



Pegged to a predefined calendar 



Date when the aggregate production plan was 
created (based on the time resolution) 
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15 



20 



25 



30 



35 



40 



45 



Aggregate Repair Plan Data 

Data related to the aggregate repair plan for the repair item identified in 



Field Identifier 


Field Description I 


RepairPlanDatalD 


Identifier for the Repair Plan Data 1 


TinePeriod 


Tine period ntanber 1 


RepairPlanHeader 
ID 


Repair Plan Bead identifier (aee aggregate repair 1 
. plan Header table) 1 


Quantity 


Number of units to be repaired R 


ProposedChange 


Reconnended change in the planned quantity (to store H 
changes between regeneration of Repair Plans) | 



Component Estimation Header 

Header file defining the Conponent X Time values for various conponent 



1 Flela loentxtxer 


Fiexa oescrxpbxon i 


1 ConyBstHesderlD 


Component Bstimatlon Header Identifier 1 


1 ComponentID 


header 1 


1 BOMID 


Utiique Identifier for BOH 


DateCreated 


Date when the component estimation was created (based 
on the time resolution) 


TimeResolution 


D for day; W for wee)c; F for bi-wee)ay; M for 
monthly; B for bi-monthly; Q for quarterly; and A for 
annually. R 


Calendar ID 


Pegged to a predefined calendar 1 


RepairPlanID 


Pegged to an aggregate repair plan (if warranted) | 


Component Estlmatic 
Data related to rec 


m Data 

luirements for the component identified in the header 


1 Field Identifier 


y 

Field Description 


1 ConpBstX>ataID 


Component Estimation Header ID (See Component 
Bstimatlon Header Table) 


H TimePerlod 


Time period number 


11 ConiRectHeaderlD 


Identifier for the component estimation header 


1 Quantity 


Number of units during the time period 1 


y ProposedChange 


Proposed Change in required quantity I 
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Material Delivery Schedule Header 

Header file defining the Coo^onent X Sillier X Time reaolutiona & valties 
for varioua material delivery schedules 



Field Identifier 


Field Description | 




XBgn V A t AC* £wjt b>xi0 nKwBAAAA wAAvafj^ o cnccmx c ■ 

Header 1 


CooponentSt^plytftxie 
ID 


Identifier for con^onent supply node 


SupplierlD 


Supplier associated iirith a Material Delivery 
Schedule 


TimeResolution 


D for day; w for wee)c; F for bi-wee)cly; M for 
monthly; B for bi-monthly; Q for quarterly; and A 
for annually. 


Calendar ID 


Pegged to a predefined calendar 


DateCreated 


Date when a Material Delivery Schedule ms created 
(bsuied on consistent time units) 



20 



Material Delivery S c h edu le Data 

Material Delivery Schedule for the Component identified in the header 



1 Field Identifier 


Field Description | 


1 MDSDatalD 


Identifier for Material Delivery Schedule Data 1 


DeliveryDate 


Material Delivery Date 1 


MDSHeaderlD 


Identifier for the Material Delivery Schedule Header 1 


Quantity 


Number of units of material delivery H 



Requirements Information 
Requirements History Header 

Header file defining Equipment X Repair Item X Time resolutions t values 
for various demand histories 



1 Field Identifier 


Field Description | 


1 Re^HistHeaderlD 


Identifier for a requirements history header | 


1 RepairltmResolution 


P for repair item; G for repair item Group; A for 1 
all repair items 1 


1 RepairltemID 


Repair Item associated with requirements history | 


EquipmentResolution 


C for Equipment; CG for equipment group; A for | 
all equipment H 


Equipment ID 


Equipment (Group) associated with requirements 
history 


TimeResolution 


D for day; W for %#ee)c; P for bi-wee)cly; M for 
monthly; B for bi-monthly; Q for quarterly; and A 
for annually. 


1 CalendarlD 


Pegged to a predefined calendar 
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Requirements History Data 

Data for the demand history for the product defined in the header 



1 Field Identifier 


Field Description 


ReqBistDataXD 


Requirraents History Data identifier (see 
Requirements History Header table) 


TimePeriod 


Time period number 


Re^iistHeaderXD 


Identifier for a requirements history header 


RequirementsQty 


Requirements Quantity 


Equipment Repair Orders 

Data for actual equipment repair orders 


Field Identifier 


Field Description 


RepairOrderlD 


ID for the actual eouimient irsDa^p oTdftr 


LineltemID 


Itine item within the ordAr 


RepairOrderRefHO 


Repair order identifier 


EquipmentID 


Equipment identified with the order 


1 RepairltemID 


Repair Item associated with the order 


1 Calendar ID 


Pegged to a calendar 


TimeResolution 


D for day; W for week; F for bi-weelcly; M for 
monthly; B for bi-monthly; Q for quarterly; and A for 
annually. 


OrderEntryDate 


Bsqpressed in terms of the calendar and time 
resolution 


RequestedDate 


Expressed in terms of the calendar and time 
resolution 


DueDate 


Expressed in terms of the calendar and time 
resolution 


1 ShipDate 


Sjqpressed in terms of the calendar and time 
resolution 


DeliveryDate 


Expressed in terms of the calendar and time 
resolution 


Quantity 


Quantity of the order 


ConntentB 


Such as value added services associated with the 
order 
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Future Requirements Header 

Header file defining the Customer X Product X Time resolutions & values for 
variotis future requirements 



Field Identifier 


Field Description 1 


FutureRe<|HeaderID 


Future Requirments Header Identifier | 


Repair I tenlResolut ion 


P for Repair It«n, 6 for Repair Itm Group, A 
for all Repair Items 


RepairltemlD 


Repair Item (Group) associated with forecast 


BquipmentResol ut i on 


C for Bcniioment. CO for ecniinment qroup s A for u 
all equipment 1 


Equipment ID 


Equipment (Groiq>) associated with requirements 1 
nxscory g 


TimeResolut ion 


D for day; W for week; F for bi-wee)cly; M for 
monthly; B for bi-monthly; Q for quarterly; and 
A for annually. 


Calendar ID 


Pegged to a predefined calendar 


DateCreated 


Date «^ien the forecast was created (based on the 
time resolution) 


FutReqType 


B for bottom-xjq^; T for top-down 


SstimationAssun^tiona 


Assumptions associated with the estimation 


BstimateOwner 


Author of the future requirements 



Future Requirements Data 

Data associated with the future requirements for the equipment -repair items 
identified in the header 



1 Field Identifier 


Field Description | 


PutureReqDatalD 


Future requirements data series Identifier 1 


TimePeriod 


Time period number B 


FutureReq^aderlD 


Pegged to the Future Requirements Header Table 


BstimateValue 


Future requirements data valuie 


BstimateCV 


Coefficient of variation of estimate 
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Activity Header 

Header file defining the Equipment Group X Repair Item X Time resolutions & 



1 Field Identifier 


Field Description 


1 ActivityHeaderlD 


Identifier for the Activity Header 


BquipmentResolution 


Equipment Group Resolution: C for Equipment, G 
for Bminnent GmouD. A fof all 




JLU I. lie csj^Aymeow ttaovw^nbou wxb>u wiip • Awwxvxwjf^ 




Repair Item Group, A for all 


1 RepairltemID 


Repair Item associated with the activity Data 


1 TimeResolution 


D for day; W for wee)c; P for bi-veeUy; M for 
monthly; B for bi-monthly; Q for quarterly; and A 
for annually. 


1 CalendarlD 


Pegged to a specific calendar 


ActivityType 


Company wide, location level, etc. 


ActivityClass 


Activity class 


Activitylntenaity 


Intensity of the activity (low, medium, high) 


ActivityShapelD 


Intensity of the activity (low, medium, high) | 



Activity Data 



Field Identifier 


Field Description | 


ActivityDatalD 


Activity Data Series Identifier 


TimePeriod 


Timer period number (beginning of the time period) 1 


ActivityHeaderlD 


Activity Header Identifier | 


ActivityDuration 


Time duration for the activity 


Pre- 

evalxiationOty 


Estimate before the activity for the quantity due to 
the activity 


Post- 

evalxiationQty 


Estimate after the activity for the quantity due to 
the activity 
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Inventory Information 
Inventory Header 

Header file defining the Repair Item X Time resolutions k values for 



1 Field Identifier 


Field Description 1 


1 InventoryReaderlD 


Inventory Data Series Identifier R 


1 Invent oryNode ID 


Identifier for an inventory logic warehouse 1 


B InventoryContTOlID 


Identifier for inventory control parameters 1 


1 IteiAResolution 


Item Resolution: C for Conqponent, P for Product, Q 
for Product Group and A for All 


RepairltemID 


Repair Item ID 


TimeResolution 


D for day; w for week; F for bi-weekly; M for 
monthly; B for bi-monthly; 0 for quarterly; and A 
for annually. 


Calendar ID 


Pegged to a predefined calendar 


1 MinlnventoryLevel 


KiniiRum inventory level for the item 


1 MaxInventoryLevel 


Maximum inventory level for .the item 



Inventory Data 

tovmtor^^ataMfor^items identified in the header^ 



Field Identifier 



Field Description 



InventoryDatalD 



Inventory data identifier (see Inventory Header 
table) - 



TimePeriod 



Time period number 



InventoryHeaderlD 



Inventory Data Series Identifier 



OnHandlnventory 



On-hand available inventory for allocation 



onOrderlnventory 



Qn-order inventory 



BadcOrderlnventory 



Back- ordered inventory 



InTransit 



In-transit quantity 



Reservedlnventory 



Reserved inventory on-hand but available for 
allocation only in case of «nergency 
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Inventory Parameters 

Data for the inventory control parameters 



} Field Identifier 


Field Description 


uivenwoxy^on&xwx 


T^AtV1^4 ^4 AlP ^^IF 111 lit <>■ «■ ■* jfc — M . Ji 1 1 nni» 

AOCMbAX aCa XwX jJuVellwwXy COuwXwX pmEalOBb-CxV • MmmUMM 

inventory planning* inventory control 


■Sa£etyStockFactor 


Safety stock factor 


TargetServlceljeveX 


Target service level 


PolicyType 


Policy type: SS, Mln/MaXr QR. etc. 


NinXnventoryPactor 


Minimum inventory factor (e.g., in terms of weeks 
of sales) 


MaxXnventoryFactor 


Maximum inventory factor (e.g., in terms of weeks 
of sales) 


1 NinOrderQtyFactor 


Minimum order quantity factor 


1 CarryChargeFactor 


Carrying cost factor 


1 OrderCbargePactor 


Ordering cost factor 


R InventoryClass 


Inventory classification 


1 ReplenisfamentPrequ 
H ency 


Frequency of replenishment w.r.t. the time 
resolution in the header 
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Repair Resource Information 

Information related to the repair technician and test equipment 
Repair Resource 



Data related to re] 


>air resource 


1 Field Identifier 


Field Description | 


1 RepairResID 


Unique identifier for a repair resource (e.g., FAIG) 1 


RepairResHaroe 


Descriptive name 1 


1 RepairResGrovqpID 


Repair resource group this resource belongs to U 


1 MaxLineRate 


Maximum line rate H 


1 IloHor)cstations 


Nunher of %#orkstations R 



40 Repair Resource Group 

Data related to production resource 



II Field Identifier 


Field Description R 


1 RepairResGroupID 


Unique identifier for the repair resource group R 
(e.g., Plant4) H 


H RepairResGroupName 


Descriptive name || 


1 RepairNodelD 


Repair node this group belongs to h 


1 Attrlbutel 


Attribute (e.g.. Category, Location) H 


1 Attribute2 


Attribute (e.g.. Category, Location) R 


B Attributes 


Attribute (e.g.. Category, Location) R 
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Interim Design Docxunentation £or the System Integrator 
of the Supply Frame Chain Manager 

Class name: 

FrameManager 

Category: Supply Frame Chain Manager 
Documentation : 

This is a singleton class. It is running on the server. 
It has to be started before a client can start and make 
connection to it. The FrameManager is responsible to 
facilitate the integration of the client side of the 
system (the User Interface 18) with the server side of 
the system where the mathematical Model Engines and the 
D3S 10 database reside. The FrameManager is con^sed of 
a ClientManager , a ServerManager, a collection of 
Request Interpreter and objects which form the Functional 
Integrator 312. When a client program start up^ it will 
connect to the FrameManager (obtain the object reference 
of the FrameManager) and call the initialization 
function. As part of the initialization of the client 
with the FrameManager, a Request Interpreter object will 
be created, inserted into the collection and the object 
reference will be return bac)c to the client. The client 
will also be registered with the ClientManager object of 
the FrameManager. The initialization also includes the 
user authentication. 
Export Control: Public 
Cardinality: 1 
Hierarchy : 
Superclasses : none 
As soc iat ions : 

<no rolename> : ClientManager in association 
<no rolename> : Request Interpreter in 

association 

<no rolename> : ServerManager in association 
Public Interface: 
Operations : 

FrameManager 
init ial i zeClient 

Private Interface: 
Attributes : 

mClientManager : ClientManager 
mServerManager : ServerManager 
mRequest Interpreter : 

List<RequestInterpreter> 

A linked list of 
Request Interpreter. Each Request Interpreter will run in a 
separate thread or a separate process. This way, requests from 
multiple clients can be handled concurrently. 

State machine: No 

Concurrency : Sequent ial 

Persistence : Transient 

Operation name: 
FrameManager 

Public member of : FrameManager 

Arguments : 

char* f raraeMgrConf igFi le 
Document at ion : 

This is the constructor is the FrameManager. At the 
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10 



construction time, it will read in the configuration 
information from a file ("frameMgrConfigFile") . The 
information include things such as the name of the DSS 
Database and on which host it is running, where are the Model 
Engines (installed on which machines), how many n\imber of 
simultaneous client are allowed to connect to the 
PrameManager, etc. The constructor is also responsdLble to 
initialize all other data member of this class. 
Concurrency : Sequential 
Operation name: 

initializeClient 
Public member of : FrameManager 
Return Class: Request Interpreter& 
Arguments : 

char*userName 
char*hostName 
char *pas sword 
NbtifyMsg&notifyMsg 
Documentation: . j t 

Once the client program has started and obtained the 
object reference of the FrameManager, it will call this 
^ function to initial itself with the Pramrtlanager . It will 

pass in, the user name, password, host name, etc. The 
information will be used for authentication and registering 
with the ClientManager. The object reference of a NotifyMsg on 
the client side will pass in. This object reference will be 
used to notify the client about its request when it make an 
^ asynchronous request. (Asynchronous request will be allowed 

when the client request to run some of the strategic decision 

model.) . , * 

This function will return the object reference of a 
Requestlnterpreter through which the client will make all its 
requests . 

30 Concurrency : Sequent i al 

Class name: 

CI ientManager 
Category : Supply Frame Chain Manager 
Documentation: 

Manage and monitor the client connection. Implement 
35 client connection policy, such as "after certain period of 

inactive time disconnect the client", "the total number of 
client connection can not exceed certain number". Also 
resposible to delete the corresponding Requestlnterpreter 
object after a client is disconnected (in such case as the 
client machine goes down, or the network connection is lost) . 
40 Export Control: Public 

Cardinality:! 
Hierarchy: 
Superclasses : none 
Associations : 

<ho rolename> : FrameManager in association 

45 Piiblic Interface: 
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Operations : 



Private Interface: 
Attributes: 



regi s t erCl lent 
mai t a inCl ient 



clients : I*ist<Client> 

A linked list of Client. The 
Client class contain the basic information about the* client, 
such as, the user name, the. client host name, the 
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corresponding Request Interpreter, time of initial connection, 
time of last request, pending requests, etc. 

State machine: No 

Concurrency : Sequent ial 

Persistence : Transient 

Operation name: 

registerClient 

Public member of :ClientNanager 

Retvim Class :bool 

Arguments: 

Client&aClient 
Documentation : 

Add a client to the client list. Enforce the relevant 
FrameManager policy such as the maximum number of simultaneous 
client . 

Concurrency : Sequential 
Operation name: 

maitainClient 
Public member of : ClientManager 
Documentation: 

This function will be called periodically from the 
FrameManager. Within the f\inction, each client will be 
checked to see if it needs to be disconnected. If a client 
needs to be disconnected, it will be removed from the list and 
the corresponding Requestlnterpreter object will be deleted. 
Concuxxency : Sequential 
Class name: 

Requestlnterpreter 
Category: Supply Frame Chain Manager 
Documentation : 

This is the object the client is normally interact 
with. Each object of this type has to run in its own thread or 
process so that multiple client can request server services 
concurrently . 

Export Control : Public 
Cardinal i ty : n 
Hierarchy : 

Superclasses mone 
Associations: 

<no rolename> : FrameMcuoager in association 
Public Interface: 
Operations: 

request 

Private Interface : 
Attributes : 
theClient : Client* 

Reference to the client with whom this 
Interpreter is associated. 
State machine :Ko 
Concurrency : Sequent ial 
Persistence : Transient 
Operation name: 
request 

Public member of : Request Interpreter 
Return Class :bool 
Arguments : 

longscenarioID 

longdomainID 

longrequestID 

boolasynch 

long&resultlD 
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Documentation : 

This ftmction will be called by the client to make a 
request to perform certain task by the server (s) . The 
scenarioID and domainID will identify the data associated with 
the request. The requestID will identify what kind of action 
need to be performed (by looking up a table within the 
system). If the request is not asynchronous ("asynch" false") 
the result will be returned immediately through the value of 
resultlD. The client can retrieve the actual data from the 
DSS Database through the resultID in the table associated with 
that type of request. If the request of synchronous, the 

result will be sent to the client later by calling the 
NotifyMsg object of the client. 

Concurrency : Sequential 

Class name: 

ServerManager 

Category : Supply Frame Chain Manager 

Documentation : 

Manage the server connection. A server is a program 
(an object) from which we can request specific service. For 
example, we may have a server being able to compute the 
optimal delivery frequency given the maximum inventory and 
service level cozistrain in a VMR setting. This is referred as 
Model Engine Server. A Model Engine Server can run on the 
same machine where the PrameManager is running, or it can run 
on different machine. Two Model Engine Servers of the same 
type can run on the saune machine, or they can run on different 
machines. The information governing the policy is stored in 
the PrameManager configuration file which was read in at the 
time of constructing the PrameManager. The ServerManager will 
enforce the policy such as on which machine to start which 
server, load balancing, etc. The ServerManager is also 
responsible to shutdown the servers when they are not needed. 

Export Control : Public 

Cardinality : 1 

Hierarchy: 

Superclasses : none 

Associations : 

<no rolename> : PrameManager in association 

Public Interface: 

Operations : 

addServer 

roaintainServer 

getServer 

Private Interface: 
Attributes : 

servers : Li8t<Server> 

A linked list of Server 
object. A Server is a class which record the basic information 
adx>ut a semrer, such as name, type, which host it is running 
on, status, etc. 

State machine: No 
Concurrency : Sequential 
Persistence : Transient 
Operation name: 
addServer 
Public member of : ServerManager 
Return Class :bool 
Arguments : 

char*aServer 
Dociimentation : 
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Try to -start a new server of certain type and add it 
to the server list. Here some of the server management policy 
will be enforced. For example, we may have a policy says that 
there should be no more than x number of Linear Programming 
servers in the entire system. Or we may have another policy 
says that we can not put more than x number of servers (of all 
types) on machine A. When the function is called only the name 
(type) of the server is passed in. Which machine the server 
should be on is determined within this function. 

Concurrency : Sequential. 

Operation name: 

maintainServer 

Public member of :ServerManager 

Documentation: 

This function is periodically called from 
FrameManager. It will check each server to see if any one 
needs to be shutdown. 

Concurrency : Sequential 

Operation name: 
getServer 

Public member of : ServerMcUiager 

Return Class : Server & 

Arguments : 

char*aServer 
Documentation : 

Return a server of the specified type. It first 
check the server list to see if any one of that type is idle. 
If it is, it return the reference to that one and update the 
status. If not, it will call the addServer function to try to 
add one. 

Concurrency : Sequent ial 



dalrns 

1. A dectskxi support system, connprising: 

dedston support frames providing a view into a supply chain; 

a model engine comprising modeling processes analyzing the chain; and 

a frame manager managing the execution of the nwdeling processes to provide information for said frames. 

2. A system as recited in claim 1 , further comprising a datat>ase managemerrt system supplying datat>ase information 
to the modeling processes and said frame manager. 

3. A system as recited in claim 1 , wherein said system comprises a server mode including said engine arxJ said man- 
ager and a client motie comprising said frames. 

4. A system as recited in claim 1 , wherein said database comprises an inventory data space, a supply data space arxJ 
a demand data space. 

5. A system as recited in claim 2, wherein said database includes a supply chain network including a component sup- 
ply node, a production node, an inventory node and a demand node. 

6. A system as recited in daim 1 , wherein said nxxleling processes comprise a component procurement policy devel- 
opment HfKxlule. a finished goods distribution networii design module, an aggregate production planning module, a 
finished goods inventory management module, a sales forecasting and planning nxxiule, a martlet data arvalysis 
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module and a vendor managed replen^ment modiia 

7. A system as recited in claim 1 , wherein said manager comprises a system integ'ator and a functional integrator. 

8. A system as recited in daim 1 , wherein the supply chain includes sales, inventory and production. 

9. A decision support system, compr^ng: 

decision support frames integrating analytical models of a supply chain responsive to a view point of a busi- 
ness process. 

10. A system as recited in daim 9. wherein said frames comprise a supply management frame, a demand manage- 
ment frame, a vendor managed replenishment frame, a planning, sales and inventory frame and a distritxition net- 
work frama 

11. A system as recited in daim 10, further comprising a domain mar\agement process limiting data available to said 
frames responsive to a user selection. 

12. A system as recited in daim 9. further comprising a scenario management process providing scenarios for conrf- 
parison of management ptens. 

13. A decision support system, comprising: 

a demarvj and supply recondliatton process recondlihg production, sales arxi inventory. 

14. A system as recited in daim 13, wherein said process determines a feasibility capacity plan responsive to supply 
constraints. 

15. A system as recited in daim 13. wherein said process provides a vendor replenishment plan responsive to pre- 
dicted sales and supply constraints. 

16. A system as recited in daim 15, wherein the plan considers production capacity, Inventory and point-of-sale infor- 
mation. 

17. A system as recited in daim 15, wherein the plan provides a strategic analysis using quantative nuxiels. 

18. A system as recited in daim 13. wherdn said process recondles a topclown forecast with a bottom-up forecast. 

19. A system as recited in daim 18. wherein said bottom-up forecast indudes an eocpert k>ased model. 

20. A storage media, comprising a recondliation process recondling production, sales and inventory of a supply chain. 

21. A decision support system, comprising: 



a dient comprising: 

dedsion support frames providing a view into production, sales and inventory of a supply chain, said 
frames integrating analytical models of a supply chain responsive to a view point of a business process, 
said frames comprising a supply management frame, a demand management frame, a vendor managed 
replenishment frame, a planning, sales and inventory frame and a cfistribution network frame; and 

a server corrprising: 

a model engine, comprising: 

nxxleling processes analyzing the chain, said nrKxjeling processes comprising a component procure- 
ment pdicy devek>pment module, a finished goods distribution network design nxxJule. an ^gregate 
production planning module, a finished goods inventory mar^agement module, a sales forecasting and 
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planning nrKxiule, a mark^ data analysis module and a vendor managed replenishment nxxiule; and 

a demand and supply reconciliation process recondling production, sales and inventory by reconciling 

a top-down forecast with a bottonvup forecast including an expert based model; 

a capacity process determining feasbilrty of a capacity plan responsive to supply constraints; 

a replenishment process providing a vendor replenishment plan responsive to predicted sales and 

supply constraints said process reconciles a top-down forecast with a bottom-ijp forecast; 

a scenario management process providing scenarios for comparison of management plans; 

a frame manager managing the execution of the nxxieiing processes to provide information for said 

frames, said manager comprising a system integrator and a functional integrator; 

a datat>ase management system supplying datat)ase infbmfration to the modeling processes and said 

frame manager; and 

a domain management process limiting data available to said frames responsive to a user selection. 
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DSS System Architecture in the Context cfMam^acturing Supply Chains 



FIG.1 
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DSS System Architecture in the Context of Equipment Repair Supply Chains 



FIG. 2 
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The Data Spaces in Supply Chain Management 

FIG. 3 
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Supply Cliatn fnrormaiton Systems 



Decision Support Thread 



FIG. 4 
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Decision Processes in the Mant^cturing Supply Chain 

FIG. 8 



164 



EP0770 967A2 



\00 




Repair Shop Operating Location' 



High Level Model of an Equipment Repair Supply Oudn and the Decision Processes 



FIG. 9 



165 



EP0770967A2 




166 



EP0770 967A2 





Modules 


Associated 
Data Spaces 


Sales Foiecastiiig & Planning 


© 


Market Data Analysis 


©HI 



Data Space Associations cfthe Demand Management Frame 

FIG. 1 1 



167 



EP0770 967A2 



POO 




Customer 



Process Flow of the Demand Management Frame 



FIG. 1 2 



168 



EP0770967A2 



1 




3iOO 



SUPPLY 
OKDERDATA 



15/ 



Back-orders & 
Expedites 



lib 



1 



DEMAND 
HISTORY 
DATA 



Uipdate History 



Actual 
Demand 



c :> 

Vj CUSTOMER 
ORDERS 




INVENTORY 
DATA 



T 



Ihvaitory 
Status Inventory 
Update 




Order Order 
Enquiry Confirmation 



Order Entry 



Customer 



Process Flow of Order Fu^lment 



FIG. 1 3 



169 



EP0770967A2 



__1 



PROMOTION 
DATA 



POS DATA 



138 



160 



Z 



CUSTOMER 
ORDESS 



140 



MARKET 
DATA 




\6X 



Sales Plan 




154 



Customer-Demand 
History 



FORECAST 

DATA: 
Bottoni'Up &■ 



i 



DEN4AND 
ORIEhnATION 
DATA 




/3G 



DEMAND 
HISTORY 
DATA 



Data Flaw for the Demand Mjanagemeni Frame 

FIG. 1 4 



170 



EP0770967A2 



V 


Modules 


Associated 
Data Spaces 


Sales Forecasting & Planning 


O 


Aggregate Production Planning 


V 


Finished Goods Inventory Management 





Data Space Associations cfthe Producthn-SaleS'Inventory Planning Frame 



FIG. 1 5 



171 



EP0770967A2 



136 



DEMAND HISrORY 
DATA 



Iff, 



1 



7 



FORECAST DATA: 



i i 

l\ 

> II < 

Hi ; 

ih' » 

: t i 

ilij 



nOVENTORYDATA: 
Requirements 



!5' 



I" t 



Itf- 



170 




FORECAST DATA: 
Top-Down 



FGIM 



1 



PSI 

Reconciliation 



SF&P 



i" ' 



i U 

1 4' 

1 



INVENTORY 
PARAMETERS 



17^ 



APP 




< 1 





174- i 



|?0 



REQUIREMENTS 
DATA 



\S3i 



PRODUCTION 
CAPACTTY 
DATA 



INVENTORY 
DATA: 
Status 




INVENTORY DATA- 
Component 
AvaUabUity 



Process Flow of the Production-Sales-Inventory Planning Frame 



FIG. 1 6 



172 



EP0770 9G7A2 





INVENTORY DATA: 
Status 



INVENTORY DATA: 
Component 
AvaUability 



PRODUCTION 
CAPACITY 
DATA 



l«0 



INVENTORY 
PARAMETERS 



1^ 




FORECAST DATA: 
Bottom-Up & 
Top-Down 



PRODUCnON 
REQUIREMENTS 
DATA 



PSI Plan 




Data Flonvfbr the Prodnction-Sales-Inventory Planning Frame 



FIG. 1 7 



173 



EP0770967A2 



V 


Modules 


Associated 
Data Spaces 


Component Procurement Policy 
Development 




Aggregate Production Planning 


V 


Finished Goods Inventory Management 





Data Space Associations cfthe Supply Management Frame 

FIG. 1 8 



174 



EP0770 967A2 




PRODUCTION 
REQUIREMENTS 
DATA 









PLANNING 




DEUVERY 


BOM 




SCHEDULE 






DATA J 




INVENTORY DATA: 
^ AvaflabOity ^ 



Process Flow of the Supply Management Frame 



FIG. 19 



MS 



EP0770 967A2 



INVENTORY 
DATA: Status 



MATERIAL 
DEUVERV 
SCHEDULE DATA 



' SUPPLY 
; CONTRACT 



/74 



PRODUCTION 
REQUIREMENTS 
DATA 

^ 



A 

80 



PRODUCTION 
MATRIX 




Master 
Production 
Plan 



4 



PRODUCTION 
CAPACITY DATA: 
Long-term 



COMPONENT 
REQUIREMENT 
DATA: Long-tenn 



Xi 



PRODUCTION 
CAPACITY DATA 



A 

500 



AGGREGATE 
PRODUCTION 
PLAN DATA 



Date Flaw for the Supply Management Frame 



FIG. 20 



176 



EP0770 967A2 



PRODUCTION 
MATRIX 



PRODUCTION 
CAPACTTYDATA 



l?0 




3D0 



AGGREGATB 
PRODUCTION 
PLAN DATA 



Production 
Capacity Flan 



Data Flow for the Supply Management Frame 

FIG. 21 



177 



EP0770 9G7A2 



V 


Modules 


Associated 
Data Spaces 


Market Data Analysis 


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 


Sales Foiecastiiig &. Flaiming 




Finished Goods Inventoiy 
Management 




Vendor Managed Replenishment 





Data Space Associations of tte Vendor Managed Replenishment Frame 

FIG. 22 



EP0770 967A2 



P05DATA 



v 



\5l 




PROMOmON 
DATA 




■ l] ; 
■ ' i 



Customer 

jCQ 



JLJL 



VMR 
Strategic 
Planning 



! MDA 

>1 



FGIM 



^ Bnandal & Business . lA 


Requirements | | 












.V i 



560 



SF&P i 



I INVENTORY DATA: 

Replenishment 
'^^^Ilfiquirements ^ 



VMR CONTRACT: 
Policy & Target 



'I 



I 



SUPPLY CHAIN 

NETWORK: 
Transportation 
Factors 



ij Replenishment 
II Planning 



I 



MKUAIAT 
Replenishment 
Schedule 




' FORECAST 
• DATA: 
J" Bottom-up 




Process Flow of the Vendor Managed Replenishment Frame 



FIG. 23 



179 



EP0770967A2 



! SUFPLYCHAIN 
I NEIWORK: 
• TntmpCKUAoa 
F<cto»8 



1 



Rcpladsfanacnt 
Rcyiii tint ntt 



! INVENTORY DATA; 
Status 



Replenishment 
Sdiedule 



i 




VMRCONntACT: 



VMRDATA: 
RBplaiisimcRt 
Sdvdule 



H FORECAST DATA: 



146 



Data flow for the Vendor Managed Replenishment Frame 



FIG. 24 



180 



EP0770967A2 



V 


Modules 


Associated 
Data Spaces 


Maiket Data Analysis 




Sales Forecasting & Planning 




Finished Goods Inventoiy 
Management 




Finished Goods Distribution 
Netwoik Design 


V 



Data Space Associatians cfihe Distribution Network Design Frame 



FIG. 25 



181 



EP0 770 967 A2 





MARKET 

dataI 



PRODUCTION 
NODE 



PRODUCTION ! 
CAPACTTY ! 
DATA 



I 



13^- 




MDA 



SF&P 



|3i 



i 



146 



C 



FORECAST 
DATA: 

~~ i 

I_ 



SPlSb 

Z 



FGDND 

X — 



14,4 



'7A 



5^6 




FGIM 

— I 



2 



INVENTORY 
NODE 



SUPPLY CHAIN 
NETWORK: Link 
Infonnation 



"I INVENTORY j 
lE ARAMETTO g; 



INVENTORY 
HEADER: Prtxluct ^ 
Assignment 



Process Flow of the Distribution Nettoork Design Frame 



FIG. 26 



182 



EP0770967A2 



J 



FREIGHT RATE 



PROTUCnON 

CAPACITY 
<^ DATA ^ 



m 



DAT A: Aggregate 
Forecasts 



INVENTORY 
PARAMETERS 



INVENTORY 
HEADER* PMxluct 
Assignment 



Wm Distribution 
Network 





SUPPLYCHAIN 
NETWORK: link 
Information 






DEMAND NODE 

h 

1 PRODircnoN 

NODE 



INVENTORY 
NODE 



Y 



300 Customer-DC 
Assignment 



Supply-DC 
Assignment J 



I 30^ 



Data Flow for the Distribution Network Design Frame 



FIG. 27 



183 



EP0770 967A2 



Component Procurement 



~j Policy Dcvelopmeiit 



t 



AggrcgEte Pioductioii 
Planning 



Finished Goods Distribution \y 
Network Design | 

f ; 



Information 
Material 



Finished Goods 
[nventoiy Mgt 



Vendor-managed 
Replenishnnent 




Saks Forecasting 
and Planning 



1 



MaricetData 
Analysis 



1 



customers 



component 
iactory 



finished-goods 
&ctory 




Seven Modules and Supply Cham Management 

FIG. 28 



184 



EP0770 967A2 



Ciimiiimwl 


i 


















B 


c 






20% 




Products 



Pareto Analysis for ABC Class^mtim 



FIG. 29 



185 



EP0 770 967 A2 



VblatiSty 


i 










D 

▲ 


▲ 

E 

A 


F 

A 






C 


A . 

B 

A 


A 












Sales 



Scatter Plot for Sales-Volatility Class^tion 

FIG. 30 



186 



EP0 770 967 A2 




187 



EP077D967A2 





















0 







Curve Fitting far Promotion ^Jcrt Analysis 



FIG. 32 



188 



EP077D967A2 




System Level Services, the Seven Modules and Model Engine Utilities 

FIG. 33 



189 



EP0770 967A2 




3 



Supply Chain Frame Manager: High Level Ardutecture 

FIG. 34 



190 



EP077D 967 A2 



314 




CLIENT 



Client 
Manager 



Request 
Interpreter 



3a4 



1 



Server 
Manager 



310 



SERVER 




High Level Architecture of the System Integrator 



FIG. 35 



191 



EP077D967A2 



has a O 



FrameManager 

-mCtientManager : QientManager 
-mServerManager : ServerManager ^ 
-mRequestlnterpreter : List<RequestlnterpreteP**^^^^^^^5 a 



+FrajmeManager( ) 
+initiartzeClient( ) 



ClientMeinager 



clients : Ljst<Client> 



registerC)ient( ) 
martainClient( ) 



Requestlnterpreter 



theCllent : Client* ! 



request( ) 



ServerManager 



servers : Ljst<Server>; 



addServer( ) 
nriaintainServer( ) 
getServer( ) 



High level object representation of the system integrator portion cftheframe manager 



FIG. 36 



192 



EP0770 967 A2 



DSS Frame Decisions 
from systems integrator 



SM 

PSI 
VMR 

DM 



Inventoxy Policy 
5S.Q,MinM« 



P line and vandon 
I line and variation 



Target Level 
Delivery Frequency 



Forecast^ 
Forecast Errors 



350 Nctwoik Simulator 



(J 



SUPPLIER 



SUPPLY CHANNEL 



CoospotttBt Req ^ 



RECONCILIATION 



Actual S' hne ▼ 



DEMAND CHANNEL 



CUSTOMER 



Netwoik Configurator 



A 



Domain Manager 



Scenario Manager 



User Access and Privileges 



Output Measures 



] 

If- 
] 



Performance Matrices 
for 

all nodes 
allchanneb 
all echelons 

Siqyply Responsiveness 
Fill Rates 
FGInventDiy 
Component Inva:itoiy 
cycle Time 
Cost 



33^ 



High Level Architecture of the Functional Integrator 

FIG. 37 



193 



EP0770 9G7A2 



/TOMPONENT^ 
NODE 



Supplier Info 
Supplier Plant 
Siq>plierDC 
Componets 



raODUCnONNODE 



ProductInfo 
Manufacturer Plant 

Bill of Material 
Pjroduction Matrix 
^Manufacturer War^touse 



|C^^ENTORYN(^::^ jC^ANDNO^ 



Customer DC 
Customer Stnre 



J 



Customer Info 
Product Req. 




Dataflow diagram for the Supply Chain Network Configurator 

FIG. 38 



194 



EP0770 967A2 



View available domains 

- Di^lay de£ault domains and 

user-defined domains. 



DOMAIN 
DATA TABLES 



View the contents of the selected domain 

- Select an existing domain. 
-Di^lay die tuples within Ihe domain. 




Edit oscMlefijted domains 
- Display each dimension of data in a tree view 
Display exiting domains. 











Load selected 
domain 



Create new nsei^efined 
domains 


Edit existing 









Add tuples 

- Select desired data from 
diree dimensions of data 
lists. 

- Disable irrelevant data in 
the oth» data lists based on 
tiie current selection 

- Unk and add the selection 
to the user-defined domain. 



Delete tuples 
-Select a tuple to 
delete. 

-Delete the selected 
tuple 



1 



Delete existing 

nserdefined 

domains 

-Sdect a domain to 
delete. 

- Ddete the selected 
domain. 



Save domains 




- Ujpdate domain tables 


► 



DOMAIN 
DATA TABLES 



FunctumaHty in the Domain Manager 

FIG. 39 



195 



EP0770967A2 




Hierarchical Structure of a Scenario 



FIG. 40 



198 



EP0770967A2 



Simulstcd 
Data Tables 



product flow 



Gcncratg Demnd 

and IcadriniB 
from dUiibu tion s 



Bnikl/Fa 
Distribatioiis 



t 



Histofy/Forecast 
i 



ConfiguiatDT 




I 



SIMULATION 
ENQME 



Define I^tJ Ajujuacc 
Measore 



Scenario Test 



Inventoiy Policy 
Pamneieis 



I 




Systeni Inicgntor 



Analytica] Decision Models 



DSS Database 



Data Flow Diagram for the Performance Simulator 



FIG. 41 



197 



EP0770967A2 



-No- 



Review Data 
& Information 



Posea 
Problem 



I 



DSS Examines 
Input 




DSS Output 



Yes 

± 



End of 
Session 



DSS 



Users 



DSS 



DSS 



DSS 




Users 

ca 



1 



Users 



User-DSS Interaction Process 



FIG 



198 



EP0770 967A2 




199 



EP0770 967A2 




Three-tier Application Devdopment Architecture 



FIG. 44 



200 



EP0770967A2 



WlndaMrs3.1-i- 
&Nr 

3?4 



r 

VISUAL BASIC 



Window* (fr 



37Y 



/5 



I 

jr. 



3t4 



User 

IniBilacB 



I? 



VISUAL C+« 



ACCESS Engine 



I 



ODBC 



SQLServer 



Supply Chain Information Systems 
(IBM SQUDS, UNIX ORACLE. el&) 



Business 
Logic 

350 



Data 

Management 



DSS Development Pla^tjrm Emrirortment 



FIG. 45 



201 



EP0770 967A2 




^Ob on the Road 



Generic System Architecture 

FIG. 46 



202 



EP0770 967A2 




System Role: 

* OLE Client 

Functional Role: 
*UI 

* Basic System 
Logic 

* Scenario Manager 

* Local DB 



Telephone 
Network 

\1 M 





System Role: 

* OLE Server 

* SNA Server 

* SQL Server 

Functional Role: 

* Model Engine 
*DSS DB 

* Scenario Data 



DB2 or other 
applications on 
*IBM 3270 
*5250 
* AS/400 

Or, UNIX 
workstation 



System Architecture 



FIG. 47 



203 



EP0770967A2 




The Logon Dialog Box 

FIG. 48 



204 



EP0770 967A2 





The Opening Screen of the DSS 

FIG. 49 



205 



EP0770967A2 




User Presences Selection Dialog Box 

FIG. 50 



206 



EP0770 967 A2 




The Select Data Domain Form 

FIG. 51 



207 



EP0770967A2 




208 



EP0770 967 A2 







Save Scenario 












NewScenariol 









% Estimated Behaviour 
^ Future Seles 
V Lost Sales 


7/1 8/96 8:22:39 AM 
7/1 8/96 8:1 8:35 AM 
7/1 8/96 8:1 9:54 AM 


7/18/96 8:22:39 AM 
7/18/96 8:18:53 AM 
7/18/96 8:19:54/^ 




Save Scenario Dialog Box 



FIG. 54 



210 



EP0770967A2 




Open Scenario Dialog Box 

FIG. 55 



211 



EP0770967A2 




^^^^^^^ JjsoL 



347 i 149 



??7 4;,37_;, 

479 : 219 



. 458 I •-1-75 3 •-.fv-596rs* ^^ _ 
; 44r1- >. 272- j ^V-872;^ 



4i^r ^^^^^^^v^>.^,^^v:^^^;^^,^v.^*.^^^^.».^.<^ 



„993 i* '..130 





763 



834 



382 



196 ! 326 



i _555 J_ 803 

«9 r'406 

]"79l" ■ '35' 



413 I 152 



619: 



jbo 

-377 
57 



791 i 33 2 ! 450 

ji'^Sj^i ; 638 

ggj' 345' j 684 

807 I 416~i 797 ] 721 

^ i [ 452 r 537 30 
j37 
275^ 



563 



. 203 [U ZSf^ 



841 



409 



724:. 



9*5 [ 384 



831": 



794 



'206;: 



730 }. 192 



773 



_973^ 



769 " I . 380 
135 1 326 



654_ 
960 



153 

'326.' 



198 



375 



95' 1 615 .j 702:-:! 



647 



383 



.369 I 326 ;i:2t4T. 



* .» ♦ » s » 



Demand Management, Bottom Up Forecast Screen 

FIG. 56 



212 



EP0770967A2 




Demand Management, Top Down Forecast Screen 



FIG. 57 



213 



EP0770 967A2 




Promotion Calendar Main Display 

FIG. 58 



214 



EP0770 967A2 




] SaeenSize 
+d Steteo 

[g^ 13P220C 



=J 19PRC10 
19PRC12 
25TRaO 
20R200C 



^ ^ AlCuslomcf* 
I ^ Top Bottom Customer* 
+ I Bottom Customers 
f: Er^ Top Customers 



^ BestPtodJcts 
^1 Customers by Region 



jPtornotion Typo ' ■-• -* *— * ^- 



[Combol H^^§]Combo2 




77i£ Promotion Selection Wizard 

FIG. 59 



215 



EP0770 967A2 




£lle £dlt ilptlons Maintanence j/gndows Help 





All Produos 



Di;^ii^nA3% I im"^ inCQO^ .'^d^'^n^ itAQQ^Jl 9^QC:91 



Progucfon(P)lirifei^, 305924 :344384 ;389944 .2^ 



SolesiES) Lifie 



Tghii|rtDfaiySUh6V 



Customerl 



Tl>-S 



267663^ 

292887 

28912b' 

291795 

269126 

289126 



94911 370804 
24186r |T56 023" 
3l"0"936"312b07 
369760 _j43M37 
372720 1366290 
369760 ;432037 
369760 U32C37 



The Main PSI Frame Form 

FIG. 60 



216 



EP0770 967A2 





Inventory Planning 
Check Capacity 



PSI Reconciliation Order 
PSI Reconciliation 



Tei 



Teiir^ortMy S Une 



CustomerT- 



OistomerZ: 



:Cus*Drt5wi34;^ 



457698 :342608 :AA3A7S 
362896 ^16439 
267663 241861 119 6023 110879 jl54709 " 0 _ Y_ .0 
29'288'7 31 0936 '5l 2007" J92310" 255>49_ "335635 34457"p339fi1 6 

289125 ■369750 ''432037' 270374 361960 3558^ 351 969 "I365048' 
291795 372720 :36629b '1253009 389059 377763 '352ll3 :418b 70 

289126 "369760 432037' "270374 351950 
289126 369750 432037 270374 "351960 




The Options menu choices on the PSI screen 

FIG. 61 



217 



EP0770967A2 




PSI Reconciliation Order Dialog Box 



FIG. 62 



218 



EP0770 967A2 




The main capacity checking dialog box - The Options tab 



FIG. 63 



219 



EP0770967A2 




The Results tab 



FIG. 64 



220 



EP0770 967A2 




The Production Resource tab 



FIG. 65 



221 



EP0770 9G7A2 




The Key Components tab 

FIG. 66 



222 



EP0770967A2 




The Bill of Material tab 



FIG. 67 



223 



EP077D967 A2 




The Alternative Components Tab 

FIG. 68 



224 



EP0770 967A2 




225 



EP077D967 A2 




Key Component Selection Dialog Box 



FIG. 70 



226 



